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

[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.

If the internal library use case is worth supporting, adding a note
tagging said internal library as not meant to be linked against seems
like a better (and much more efficient) approach? This could also
actually result in the dynamic linker rejecting attempting to load
through DT_NEEDED entry.

-- 
Kaylee Blake <klkblake@gmail.com>
C is the worst language, except for all the others.