This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

ppc-eabi: interaction betwen section name attributes and -msdata


I've run into some issues relating to the interaction of section name
attributes and the -msdata option in a powerpc-eabi toolchain.  While
I'm using gcc-2.95.2, the same issues appear to be present in gcc-3.0.

The -msdata option puts all global data objects with size less than a
threshhold (set by the -G option, defaults to 8 bytes) into the .sdata,
.sbss, or .sdata2 sections, and refers to them with sda21 relocations.
This loses when you have explicitly put a object in another section 
with a section attribute:

    int foo __attribute__((section(".foo"))) = 0;

    int
    getfoo(void)
    {
	    return foo;
    }

The code generated for getfoo() is:

	    .align 2
	    .globl getfoo
	    .type   getfoo,@function
    getfoo:
	    lwz 3,foo@sda21(0)
	    blr

which loses if you don't place ".foo" within one of the small data
sections.  A related problem is that sometimes there may be a data
object larger than the threshold that the user wants to put in a 
small data section to get the more efficient accesses.


Would it be reasonable for gcc to pay attention to section attributes
to solve these problems?  I'm thinking along the lines of the small
data relocs being used used if:

    * the size size of the data object is below the threshold and no
      section attribute was specified.
    or:

    * the section attribute was one of the small data sections.

This would require the ability section attributes to be put on extern
declarations, as they are currently only supported for definitions with
initializers.


Any advice before I go down this route would be appreciated,

	--jtc

-- 
J.T. Conklin
RedBack Networks


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]