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