[LLVMdev] Modeling ELF linker with lld/Chunks.

[Shankar Easwaram]

Thanks for the reply.



> On Jun 5, 2015, at 20:45, Rui Ueyama <ruiu at google.com> wrote:
> 
> 
>> 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.
>  
If foo is in a group, and bar is calling foo which is outside the group, it cannot refer to foo directly but use a undefined symbol to refer to it.

>> - 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/e9b94740/attachment.html>