On Thu, Feb 18, 2021 at 11:19:50AM +0100, Richard Biener via Binutils wrote: > 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.
It depends if the Binutils maintainers would accept a patch implementing ".retain <symbol_name>" in principle. If we can add ".retain <symbol_name>" to GAS, then I agree, current GCC SHF_GNU_RETAIN behavior should be removed. For GCC 12 we leverage .retain to implement the functionality where "used" saves symbols form linker garbage collection, without modifying section names or the structure of the object file. If the proposal for a .retain GAS directive is rejected by Binutils, then we should continue with the current state, where a separate "retain" attribute is supported by GCC to save a symbol declaration from garbage collection, using SHF_GNU_RETAIN. Thanks, Jozef > > 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
