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]

Re: section placement q




On Mon, 15 May 2000, Graham Stoney wrote:

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

The problem (and I bet the reason why gcc does what it currently does), is
that there are no guarantees that the section will be entirely removed. It
might be only partially used, as with the Linux use of an "initdata"
section that is used for initializations, but later dropped.

To see why this is a problem, imagine that we have such an "init" section,
and that "foo" foes into ".text.init", and the string "hello, world\n"
goes into the section ".rodata.init". Is that the right thing to do?

Not necessarily: the initialization function may set up data structures
etc, and save away the pointer to the string. Which is not all that
obviously a bug. So when (later) the init sections are free'd, you get
faulty behaviour.

This is true of function-sections as well. As long as the
function-sections are used _only_ for garbage collection at link-time, the
".rodata.foo" behaviour is the obviously correct one. But the ".rodata"
approach is at least the one that is the least likely to result in some
rather subtle bugs - there might be other, quite valid, uses of
per-function sections.

So a constant string data item is definitely different from a static
variable. Making a static variable follow the function (-fdata-sections)
makes sense pretty much all of the time. For constant strings this is not
necessarily as obviously the case if only because they are sometimes taken
for granted.

		Linus


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