Re: [RFC] SHF_GNU_RETAIN ELF Section Flag

[Carlos O'Donell <carlos@redhat.com>]

On 9/15/20 8:37 AM, Florian Weimer via Gnu-gabi wrote:
> * Jozef Lawrynowicz:
> 
>> On Tue, Sep 15, 2020 at 02:09:22PM +0200, Florian Weimer wrote:
>>> * Jozef Lawrynowicz:
>>>
>>>> I'd like to propose a new ELF section flag, SHF_GNU_RETAIN, for addition
>>>> to the GNU gABI.
>>>>
>>>> This flag instructs the linker to "retain" the section in the output
>>>> file, even if garbage collection would remove it because it appears
>>>> unused.
>>>
>>> How does this flag interaction with libraries (.a files)?
>>
>> If a section in a library has SHF_GNU_RETAIN set, and that library gets
>> searched by the linker for some undefined symbol, then the
>> SHF_GNU_RETAIN section will also be pulled into the program, and
>> retained in the linked output file.
> 
> Sorry, that's not quite what I meant.  What happens if the .o file with
> SHF_GNU_RETAIN in an .a library is not otherwise referenced and thus
> never loaded by the link editor?  How would the link editor realize that
> it is even there?

Why would it be loaded?

Why does the link editor need to detect the presence of such a file?

There is certainly a semantic layering here that needs to be teased apart
and explained in more detail.

The archive operates on whole object files.

Therefore the rules say that the whole object file is included when a
dependency would require it to be included.

While SHF_GNU_RETAIN operates on sections. So when the linker is doing
garbage collection of the included section it would keep the section.

Thus the definition of SHF_GNU_RETAIN might be:

SHF_GNU_RETAIN

  When an object file containing such a marked section is included in
  the link, the section should not be garbage collected by the linker,
  even if it appears unused.

This would do away with the archive ambiguity.

Unless we want to argue what we mean by "included in the link?"

-- 
Cheers,
Carlos.