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

[Geoff Keating <geoffk at geoffk dot org>]

jtc@redback.com (J.T. Conklin) writes:

> 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.

I'd rather have an explicit __attribute__((sdata)) and
__attribute__((nosdata)), or something.  That way you don't have to
parse section names in GCC.

It's also common to have a file where you want most of the data to not
be in .sdata, but a small number of commonly-used variables should be
in .sdata.

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

Sure.

-- 
- Geoffrey Keating <geoffk@geoffk.org>