[PATCH] Add -fgnu-retain/-fno-gnu-retain

[Jozef Lawrynowicz]

On Thu, Feb 18, 2021 at 11:22:42PM +1030, Alan Modra via Binutils wrote:
> On Wed, Feb 17, 2021 at 11:23:12AM +0000, Jozef Lawrynowicz wrote:
> > In previous discussions, it seemed to me that there was general support
> > for the "used" attribute implying SHF_GNU_RETAIN and saving symbols from
> > linker garbage collection[1]. Of course, the current implementation
> > results in undesirable behavior - the thought that all linker scripts
> > not supporting uniquely named sections would need to be updated is quite
> > alarming.
> > 
> > It's a shame that all this extra complication is required, just because
> > we cannot have a ".retain <symbol_name>", directive.
> 
> Is that true?  Isn't the problem really that retained sections are
> named as if -ffunction-sections/-fdata-sections were in force?  And
> that is due to wanting separate sections so that garbage collection
> works, since SHF_GNU_RETAIN is all about linker garbage collection.
> 
> I don't see how having a ".retain <symbol>" would help much.

In the early GCC implementations, there were issues getting the default
"unnamed" section names for symbols in GCC[1]. This prevented us from
being able to simply emit a .section directive, replacing a .text/.data
etc. directive.

H.J. improved upon my initial attempt for doing this, but then the
approach was changed to always put "used" symbols in uniquely named
sections, and I don't know why. Hopefully H.J. can clarify why "used"
symbols had to be put in sections with unique names.

With a ".retain <symbol>" directive, GCC doesn't need to work out the
section associated with a symbol, alleviating the above issues, so we
don't need to change the section a symbol is in to apply SHF_GNU_RETAIN
to that section.

The bugs we are seeing now (e.g. PR 99113) are because some linker
scripts aren't set up to handle uniquely named sections. With
".retain <symbol>", the linker scripts will work without issues because
we have not changed the layout of sections.

> 
> > My preferred vision for this functionality was:
> >   - SHF_GNU_RETAIN section flag indicates a section should be saved
> >     from linker garbage collection.
> >   - ".retain <symbol_name>" assembler directive applies SHF_GNU_RETAIN
> >     to the section containing <symbol_name>.
> >   - GCC "used" attribute emits a ".retain <symbol_name>" directive for
> >     the symbol declaration is is applied to.  Applying the "used"
> >     attribute to a symbol declaration does not change the structure of
> >     the object file, beyond applying SHF_GNU_RETAIN to the section
> >     containing that symbol.
> 
> That description seems to say that a ".retain foo" would mean
> everything in foo's section is kept.  If foo's section was the usual
> .data, you've kept virtually everything from garbage collection.

Yes, sort of. Everything from .data in the input object file - only
the .data containing foo. Unused .data sections from other object files
will be garbage collected, as required.

The user has marked "foo" as used after all, so the linker is
treating it as if it is linked to the entry point of the program in some
way. Since garbage collection only works at the section level, we can't
do any better - unless -ffunction/fdata-sections is used.

> Surely you don't expect ".retain foo" to create a separate .data
> section for foo?  If you do, I'm strongly against that idea.

No, I don't want ".retain" to change anything about the structure or
contents of a section, beyond applying SHF_GNU_RETAIN to it.

> 
> Note that gas indeed supports multiple sections named .data that can
> serve the same purpose as -fdata-sections.  See the gas doc for the
> optional .section field "unique".  That might be the best way to avoid
> an under-the-hood -ffunction-sections/-fdata-sections.

As mentioned above, there were issues getting the default "unnamed"
section names for symbols in GCC.

If we can reliably get the name of an unnamed section, then we could
potentially do away with .retain. "unique" would allow finer granularity
of garbage collection, but it is changing the structure of the object
file, which I think we should try to avoid, as it leads to issues like
we are seeing now.

Thanks,
Jozef

[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557914.html
> 
> -- 
> Alan Modra
> Australia Development Lab, IBM