[LLVMdev] Modeling ELF linker with lld/Chunks.

[Rui Ueyama]

On Fri, Jun 5, 2015 at 4:48 PM, Shankar Easwaran <shankarke at gmail.com>
wrote:

> Hi All,
>
> I have a design question of how your linker would be suitable for modeling
> ELF semantics.
>
> The ELF linker needs the functionality of reading relocations ahead of
> symbol resolution for the following usecases :-
>
> - Add linker defined symbols if there is a relocation to the symbol
> (Examples are : defsym, PROVIDE)
>

Symbol table contains both undefined and defined symbols. We know what
symbols are needed to be resolved to link that file correctly without
reading relocation table.

- Dont halt the linker operation if there are undefined symbols but they
> are not called from the root set (Do garbage collection and then report
> whether symbols are really undefined)
>

Dead-stripping is done after eliminating duplicate COMDAT symbols.
Unreferenced symbols are naturally ignored.


> - A reference to a symbol inside a group, from outside a group need to be
> through an undefined symbol
>

I don't get the meaning of the question.


> - For string merging, relocations are needed in advance before they can be
> merged.
> - For identical code folding, relocations are needed in advance before
> they can be merged.
>

These happen after symbol resolution and you need to read relocation table.


> There are also more usecase where there is not a symbol but a section,
> examples of them are :-
>
> - sections that contain mergeable strings (.rodata)
> - sections that contain Eh Frame information, where FDE's are discarded
> for functions that are garbage collected.
>
> So I was trying to figure out how the Chunks and relocations would be
> related in the Reader, which means that it would be very similiar to what
> we have with the Atom model.
>
> Thoughts / opinions ?
>
> Shankar Easwaran
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150605/3fad78d9/attachment.html>