Re: section placement q

[greyham at research dot canon dot com dot au (Graham Stoney)]

I might just comment on the items I'm particularly interested in...

Andrew Morton writes:
> -ffunction-sections
> -------------------
>
> foo()
> {
>         bar("hello, world\n");
> }
> gcc-experimental -ffunction-sections -fdata-sections -O -S fs.c
>
> In this case, the function goes in ".text.foo", but the string goes into
> .rodata.  We (Graham) would like the string in ".data.foo", I guess.

Only if -fwritable-strings is also specified. Otherwise, I think it should go
in ".rodata.foo", where "foo" is the first function that uses the string given
that read-only strings can be shared. This will Do The Right Thing(tm) in the
face of --gc-sections even if bar gets optimised away and the string is also
used by another function.

> anon strings in static defns
> ----------------------------
> 
> struct thing
> {
>         int i;
>         char *s;
> };
> 
> struct thing __attribute__ ((__section__ (".text.init"))) things[]  =
> {
>         { 12, "a string" }
> };
> 
> The string goes in .rodata.  We'd like to be able to control its
> section. In this case ".data.init".

Shouldn't this be using section ".data.init"?. I think you want all the
strings referenced in "things" go in this section too. In other words, string
literals referenced in static structs could inherit the same section as their
parent object. The compiler might need to recognise that strings in such
circumstances aren't necessarily shareable if their sections differ, so that
non-.init code which also uses "a string" doesn't break.

Regards,
Graham
-- 
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929