Re: RFC: [PATCH] ELF: Don't require section header on ELF objects

[Florian Weimer <fw@deneb.enyo.de>]

* Kaylee Blake:

> On 9/3/20 11:36 pm, Florian Weimer wrote:
>> * Kaylee Blake:
>> 
>>> On 9/3/20 6:43 pm, Florian Weimer wrote:
>>>> * H. J. Lu:
>>>>
>>>>> Section header isn't mandatory on ELF executable nor shared library.
>>>>> This patch adds a new linker option, -z nosectionheader, to omit ELF
>>>>> section header when building an executable or shared library, adds
>>>>> an objcopy and strip option, --remove-section-header, to remove ELF
>>>>> section header from an executable or shared library.
>>>>>
>>>>> The PT_DYNAMIC segment contains DT_HASH/DT_GNU_HASH/DT_MIPS_XHASH,
>>>>> DT_STRTAB, DT_SYMTAB, DT_STRSZ and DT_SYMENT, which can be used to
>>>>> reconstruct dynamic symbol table when section header isn't available.
>>>>> For DT_HASH, the number of dynamic symbol table entries equals the
>>>>> number of chains.  For DT_GNU_HASH/DT_MIPS_XHASH, only defined symbols
>>>>> with non-STB_LOCAL indings are in hash table.  Since in dynamic symbol
>>>>> table, all symbols with STB_LOCAL binding are placed before symbols with
>>>>> other bindings and all defined symbols are placed before undefined ones,
>>>>> the highest symbol index in DT_GNU_HASH/DT_MIPS_XHASH is the highest
>>>>> dynamic symbol table index.
>>>>
>>>> Does this patch enable ld to use shared objects without a section
>>>> header for linking?
>>>>
>>>> I think the NEWS and manual update should clarify this.
>>>>
>>>> In my opinion, it should NOT be possible to link against objects
>>>> without section headers.  Lack of section headers clearly marks the
>>>> object as a run-time only object.  This is useful if you want to
>>>> prevent developers to create DT_NEEDED dependencies on internal
>>>> libraries, for example.
>>>
>>> For shared objects without debug symbols, the section header table is
>>> ~2kB on average of redundant data. I'm also not a fan of the
>>> inconsistency of having shared libraries that the dynamic linker is
>>> perfectly happy to load, but ld can't link against, especially since
>>> this seems like an oversight rather than an intended design decision.
>> 
>> You didn't answer my question. 8-)
>
> Ah, yes, sorry. It does enable that; that was my primary motivation for
> my part in it.

I think that's conceptually the wrong thing to do for ELF, sorry.  If
there is no section header, the object should be unlinkable.  The
linker should not use the dynamic segment to locate the symbol
information, only the dynamic section (in case the link ABI and
run-time ABI are different).

You could still get the run-time savings by stripping the DSO and
using different (but matching) DSOs for linker input and at run time.