llvm dev - Jul 2015 - [LLVMdev] Some thought on handling ELF shared libraries in lld

On 21 July 2015 at 09:34, Dave Bozier <seifsta at gmail.com>
wrote:
> Sounds reasonable. The sstrip tool that performs stripping of the
> section header does state that this makes shared libraries unsuitable
> for static linking. From the documentation:
>
>> A shared-object library stripped in this fashion will still be usable
by the dynamic linker, but not by the static linker.
>
> That said, it should be technically possible to statically link a
> shared library with no section header table if we chose to support
> that use case. Can't you use the symbol indices of dynamic relocations
> to achieve this instead of counting the number of symbols?
It is technically possible. But we have to find the total symbols
early (symbol resolution) and so we would need to do an early scan of
another table just to find that number.

Cheers,
Rafael

> It is technically possible. But we have to find the total symbols
> early (symbol resolution) and so we would need to do an early scan of
> another table just to find that number.
That shouldn't be too expensive. I would expect roughly as many
dynamic relocations as there are symbols as they will mostly just be
patching PLT/GOT entries for them.

You could also make it easier by creating a new tag defining the size
of the symbol table. That would at least allow shared libraries
produced by lld to be able to easily parse the dynamic symbol table.

Is statically linking against shared libraries that have been stripped
of their section header tables something that is likely to be
requested?



On Tue, Jul 21, 2015 at 3:30 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> On 21 July 2015 at 09:34, Dave Bozier <seifsta at gmail.com> wrote:
>> Sounds reasonable. The sstrip tool that performs stripping of the
>> section header does state that this makes shared libraries unsuitable
>> for static linking. From the documentation:
>>
>>> A shared-object library stripped in this fashion will still be
usable by the dynamic linker, but not by the static linker.
>>
>> That said, it should be technically possible to statically link a
>> shared library with no section header table if we chose to support
>> that use case. Can't you use the symbol indices of dynamic
relocations
>> to achieve this instead of counting the number of symbols?
>
> It is technically possible. But we have to find the total symbols
> early (symbol resolution) and so we would need to do an early scan of
> another table just to find that number.
>
> Cheers,
> Rafael

On 21 July 2015 at 12:03, Dave Bozier <seifsta at gmail.com>
wrote:
>> It is technically possible. But we have to find the total symbols
>> early (symbol resolution) and so we would need to do an early scan of
>> another table just to find that number.
>
> That shouldn't be too expensive. I would expect roughly as many
> dynamic relocations as there are symbols as they will mostly just be
> patching PLT/GOT entries for them.
The dynamic relocation will cover every symbol. For example, a .so with just

void f(void) {}

in it has no relocations at all.

The hash table will cover them all. But it doesn't seem possible to easily
find
the size of the gnu hash table.
> You could also make it easier by creating a new tag defining the size
> of the symbol table. That would at least allow shared libraries
> produced by lld to be able to easily parse the dynamic symbol table.
>
> Is statically linking against shared libraries that have been stripped
> of their section header tables something that is likely to be
> requested?
No, every other linker that I know of uses sections.

Cheers,
Rafael