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

[Kaylee Blake]

On 10/3/20 1:22 am, Florian Weimer wrote:
> * Kaylee Blake:
> 
>> On 9/3/20 11:59 pm, Florian Weimer wrote:
>>> * Kaylee Blake:
>>>
>>>>> 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).
>>>>
>>>> I'm confused by your comment about link and run-time ABIs differing;
>>>> surely if the ABI at runtime differs from the ABI at link time, you are
>>>> just going to crash at runtime?
>>>
>>> No, the typical application are fewer symbols in the DSO at link time
>>> than at load time, for example for linking against an older version of
>>> glibc than is installed on the system.
>>
>> How is that being done?
> 
> libc.so is replaced with something that contains a stub library which
> only exports the intended symbols, at the right versions.
> 
> If I recall correctly, some enterprise database products are linked
> using ld against such a stub library upon installation.  It's a bit
> weird for sure, but it's what people do.
> 
>> On my machine, the symbols in glibc found through the section header
>> are identical to the ones found through the dynamic array, except
>> that some of the latter are missing symbol versions, which I think
>> is due to this patch not looking them up?
> 
> Ah, didn't know that the compat symbols (those with @ symbol versions
> instead of @@ synbol versions) are not present in .symtab.  That makes
> sense, given that they are not supposed to be linked against for new
> binaries.  We should definitely keep hiding symbols which lack a
> default symbol version.

Oh, I think I was unclear. They contain the same set of symbols, but
readelf reports the name of the symbol without any @version or @@version
suffix if reading from the dynamic array.

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