On Wed, Feb 17, 2021 at 12:25 PM Jozef Lawrynowicz <joze...@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
