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

Jozef Lawrynowicz jozef.l@mittosystems.com
Wed Feb 17 11:23:12 GMT 2021


On Tue, Feb 16, 2021 at 05:45:47PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote:
> > When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates
> > thousands of
> > 
> > ld: warning: orphan section `.data.event_initcall_finish' from `init/main.o' being placed in section `.data.event_initcall_finish'
> > ld: warning: orphan section `.data.event_initcall_start' from `init/main.o' being placed in section `.data.event_initcall_start'
> > ld: warning: orphan section `.data.event_initcall_level' from `init/main.o' being placed in section `.data.event_initcall_level'
> > 
> > Since these sections are marked with SHF_GNU_RETAIN, they are placed in
> > separate sections.  They become orphan sections since they aren't expected
> > in the Linux kernel linker script. But orphan sections normally don't work
> > well with the Linux kernel linker script and the resulting kernel crashed.
> > 
> > Add -fgnu-retain to disable SHF_GNU_RETAIN for Linux kernel build with
> > -fno-gnu-retain.
> 
> I'd say this shows that the changing of meaning of "used" attribute wasn't
> really a good idea, the Linux kernel certainly won't be the only problem
> and people use "used" attribute for many reasons and don't necessarily want
> the different sections or different behavior of those sections if they use
> it.
> 
> So, can't we instead:
> 1) restore the old behavior of "used" by default
> 2) add "retain" attribute that implies the SHF_GNU_RETAIN stuff and fails
>    if the configured assembler/linker doesn't support those
> 3) add a non-default option through which one could opt in for "used"
>    attribute to imply retain attribute too for projects that want that?
> 

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.

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.

H.J. vetoed ".retain <symbol_name>"[2], since it fails the predicate:
  Assembler directive referring to a symbol must operate on the symbol
  table.

So because of this veto, we have compromised on "code quality" so far,
since any linker script not supporting named sections, used to link an
application containing "used" symbols (now put into their own section) has
potential undefined behavior.

With the new proposed change to use a "retain" attribute, we now
compromise on functionality, since the "used" attribute saving symbols
from linker garbage collection is disabled by default. 

All because we cannot introduce an exception to the above predicate.

I would like to re-open discussions on whether a ".retain <symbol_name>
directive is acceptable. This would enable "used" to imply
SHF_GNU_RETAIN, without changing the structure of the object file,
thereby allowing the new functionality to be used without linker script
modifications.

If a Binutils global maintainer could side one way or the other on
".retain <symbol_name>" (an opinion was never given by the Binutils
maintainers when we had the discussions on that mailing list, although
Jeff did support .retain in the GCC discussions[3]), then it will be
easier to proceed knowing definitively that ".retain" is rejected and we
have no choice but to go this route of having a separate "retain"
attribute.

Thanks,
Jozef

[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557097.html
[2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558123.html
[3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558398.html


More information about the Gcc-patches mailing list