[lld] Overloaded Layout references

Hi,

I think we are overloading the Layout references for garbage collection.

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.

My thought on Layout references was that it only guarantees that atoms appear in Layout reference order.

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.

We could come up with a simpler pass for Layout(to sort atoms by file ordinal).

What do you think ?

Shankar Easwaran

I’m not sure if I understand the suggestion correctly, so let me double check.

  1. You are thinking that layout-after should affect only on layouts, and garbage collector should ignore them.2. Instead of layout-after, you suggested adding some other reference, so that all atoms from the same section will be handled as a group by the garbage collector.
  2. By doing 1 and 2, we can make the LayoutPass simpler.

Are the above points correct?

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.

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.

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.

- Michael Spencer

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