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

[Richard Biener]

On Wed, Feb 17, 2021 at 12:25 PM Jozef Lawrynowicz
<jozef.l@mittosystems.com> wrote:
>
> 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.

So I then propose, for GCC 11, to rip out / disable any use of SHF_GNU_RETAIN,
effectively restoring GCC 10 beahvior and re-consider for GCC 12.

Richard.

> 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