[LLVMdev] [lld] Overloaded Layout references

[Shankar Easwaran]

On 1/28/2015 6:28 AM, Michael Spencer wrote:
> On Tue, Jan 27, 2015 at 11:58 PM, Shankar Easwaran
> <shankare at codeaurora.org> wrote:
>> Hi,
>>
>> I think we are overloading the Layout references for garbage collection.
> one of the original points of layout references was for correct GC.
>
>> If you are creating a reference (kindLayoutAfter) from A to B, that may not
>> mean that you cannot garbage collect B for the end user.
> The way we implement ELF semantics say you can't. We can only GC
> entire sections. You can't just yank an atom out of a layoutAfter
> chain.
Garbage collection is disabled by default with GNU linker.

I think, we should not run the LayoutPass unless :-

* GC is enabled
* There is a need of sorting atoms using LayoutReferences (reordering 
atoms using an order file)

For all the default cases when GC is disabled, it should be enough that 
the layout pass sorts atoms by file ordinal, and ordinals of atoms 
within the file.

>> My thought on Layout references was that it only guarantees that atoms
>> appear in Layout reference order.
> GC is really simple right now. You just follow all references. Doing
> this would require checking each reference for if it's a "real"
> reference. While not a complicated change, it removes the purity of
> the graph model.
Ok.
>> Why are we overloading this for Garbage collection (aside from saving
>> space/code) ?
>>
>> We should create kindLive (or) some better name IMO for Garbage collection.
>> With this the complex LayoutPass can be optional and would be meant only for
>> users that need the LayoutReferences to specify layout of the image.
> The only current use of layout references is to preserve object file
> semantics. If we want to implement that some other way, we should
> remove LayoutReferences. We're already having performance issues in
> the linker, we don't really have room for any non-essential overhead.
I agree we should preserve object file semantics and LayoutReferences 
are able to already handle this and we should not design something else 
that adds more overhead.

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation