Re: [RFC] Add support for the "retain" attribute utilizing SHF_GNU_RETAIN

[Jeff Law <law@redhat.com>]

On 10/26/20 2:43 PM, Jozef Lawrynowicz wrote:
> On Mon, Oct 26, 2020 at 07:08:06PM +0000, Pedro Alves via Gcc-patches wrote:
>> On 10/6/20 12:10 PM, Jozef Lawrynowicz wrote:
>>
>>> Should "used" apply SHF_GNU_RETAIN?
>>> ===================================
>>> Another talking point is whether the existing "used" attribute should
>>> apply the SHF_GNU_RETAIN flag to the containing section.
>>>
>>> It seems unlikely that a user applies the "used" attribute to a
>>> declaration, and means for it to be saved from only compiler
>>> optimization, but *not* linker optimization. So perhaps it would be
>>> beneficial for "used" to apply SHF_GNU_RETAIN in some way.
>>>
>>> If "used" did apply SHF_GNU_RETAIN, we would also have to
>>> consider the above options for how to apply SHF_GNU_RETAIN to the
>>> section. Since the "used" attribute has been around for a while 
>>> it might not be appropriate for its behavior to be changed to place the
>>> associated declaration in its own, unique section, as in option (2).
>>>
>> To me, if I use attribute((used)), and the linker still garbage
>> collects the symbol, then the toolchain has a bug.  Is there any
>> use case that would suggest otherwise?
>>
>> Thanks,
>> Pedro Alves
>>
> I agree that "used" should imply SHF_GNU_RETAIN on whatever section
> contains the declaration that the attribute is applied to. However, I
> think that apart from the section flag being applied to the section, the
> behaviour of "used" shouldn't be modified i.e. the declaration shouldn't
> be put in a unique section.
>
> I originally justified the addition of a "retain" attribute, alongside
> "used" implying SHF_GNU_RETAIN, as indicating that the declaration
> should be placed in it's own section. In hindsight, this is unnecessary;
> if the user wants to increase the granularity of the portions of their
> program being retained, they should build with
> -f{function,data}-sections, or manually put the declaration in its own
> section with the "section" attribute.
>
> So we could shelve the "retain" attribute, and just modify the "used"
> attribute to imply SHF_GNU_RETAIN. If we get consensus on that, I could
> go ahead an implement it, but I never got any specific feedback on the
> GCC behavior from anyone apart from you. I don't know whether to
> interpret that lack of feedback, whilst the other aspects of the
> implementation were commented on, as support for the "retain" attribute.
>
> (I appreciate you giving that feedback in the Binutils discussions, and
> should have engaged in those discussions more at the time. There was
> just a lot of opinions flying about on many aspects of it, which is
> attention for this proposal I now miss...)
>
> Since I'm not proposing to modify the behavior of "used" apart from
> applying SHF_GNU_RETAIN to its section, I'm hoping the GCC side of
> things won't be too controversial.
>
> However, the assembler will have to support mis-matched section
> declarations, i.e.:
>   .section .text,"ax",%progbits
>   .......
>   .section .text,"axR",%progbits
>   .......
>
> The Binutils patch that supported this would create two separate .text
> sections in the assembled object file, one with SHF_GNU_RETAIN and one
> without.
> Perhaps they should be merged into a single .text section, with
> SHF_GNU_RETAIN applied to that merged section, so as to truly not
> interfere with "used" attribute behavior.
>
> There was an opinion that allowing these separate .section directives
> with the same name but different flags was undesirable.
>
> Personally, I don't see it as a problem, this exception is beneficial
> and makes sense, if the assembler merges the sections it is as if they
> all had the flag applied anyway.

So at a high level I agree with Pedro.  As a developer, if I marked
something as used and the linker removed it, I'd be awful annoyed.


What I think it still debatable is the implementation.  I think we
probably want a directive we pass to the assembler that says to keep the
symbol (ie, the .retain directive from the other thread).


The question then becomes how is .retain implemented.  The easy way is
to have it change the section flags under the hood to ensure the section
is never garbage collected away.  The other way would be to do deeper
surgery by making .retain mark the symbol and teach the linker about the
sematics of that new symbol flag.


Jeff