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

[Jeff Law]

On 2/18/21 3:19 AM, Richard Biener via Binutils wrote:
> 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.
FWIW concerns WRT SHF_GNU_RETAIN are the primary reason why we didn't
include binutils-2.36 into Fedora 33.  If we included binutils-2.36,
then GCC would have started using SHF_GNU_RETAIN and we were concerned
that there could easily be fallout.

Or to put it another way, I'd fully support Richi's proposal -- I fear
that folks using the combination of gcc-11 + binutils-2.36 are likely
going to stumble over real problems in this space.  Disabling those bits
or removing them from gcc-11 and reintroducing them early in gcc-12
gives everyone more time to find potential issues.

Jeff