[PATCH] Do not use layout-before to layout atoms.
ruiu at google.com
Thu Mar 27 12:33:59 PDT 2014
(I accidentally hit "reply" instead of "reply all", so sending it again.)
I'll add "alias" references if no objections from other reviewers. I'll
probably add ELF symbol aliasing support with it, so hold on.
We cannot remove kindLayoutBefore because doing it would break dead
stripping pass. We still need it for GC as GC needs backward references.
To remove kindLayoutBefore, we have to modify dead striping pass so that it
creates back references internally from forward references and use it while
collecting dead objects. I think I'm going to make such change, but it's
going a bit large.
Submitting this change first and then doing the next step in a following
patch would be better than merging the two together. Incremental change is
easier to bisect in case it would breaks omething, and it's easy to
understand for reviewers, too.
On Wed, Mar 26, 2014 at 7:28 PM, Shankar Easwaram <shankarke at gmail.com>wrote:
> Sent from my iPhone
> On Mar 26, 2014, at 21:11, Chandler Carruth <chandlerc at google.com> wrote:
> On Wed, Mar 26, 2014 at 6:30 PM, Shankar Easwaram <shankarke at gmail.com>wrote:
>> As I said before this functionality is critical for linker scripts and
> Perhaps you can clarify how it is critical? I've not really been following
> the discussion, but so far I don't see how these are strictly
> interchangeable feature sets.
> I am sure that you might have used a linker script, but anyways below is a
> short explanation.
> With lld when you want to move an atom to a different output section as
> defined in the linker script or take an order file to layout atoms, you
> would need to move the group of atoms that would need to move together as
> ELF only deals with sections. There are references within a section because
> of local symbols and what not.
>> If you do this in the elf writer that information would not be captured
>> in the YAML or the native representation.
> I don't see any discussion of the elf writer here. The claim seems to be
> that layout-before and layout-after represent the same constraint, merely
> expressed in two directions, and the code is simpler if it requires the
> constraint to always be expressed in one direction.
> Please see my latest reply on this.
>> I am not convinced, as long as the functionality is not exercised by
>> having a flag, I don't see why it impacts you at this time.
> The complexity of the pass impacts the project, always. You cannot hide
> complexity behind a flag. The question Rui is asking is why this complexity
> is needed.
> I was talking about this mirroring the idea mentioned by Nick in a
> previous email thread.
> Also I have replied with that I am ok to remove the kindLayoutBefore
> reference and the pass that deals with it. As part of that I would want to
> remove all references to the reference type which this patch does not
> address. It keeps a dangling reference in PECOFF code to make Garbage
> collection not collect, which in my opinion should use a different kind of
> reference if it's needed and not kindLayoutBefore. The kindLayoutBefore
> reference says to layout a atom before a particular atom and is designed to
> be a reference meant for the layout pass.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits