[PATCH] [ELF] Refactor File.h.

Rui Ueyama ruiu at google.com
Wed Jun 5 21:18:40 PDT 2013


Thank you for the clarification. That's very helpful. Comments inline.

On Wed, Jun 5, 2013 at 6:27 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:

>  On 6/5/2013 6:52 PM, Rui Ueyama wrote:
>
> Shankar,
>
> I tried not to change the behavior of the existing code when I was doing
> this. I splitt the function and felt like it became easier to read, but I
> still don't fully understand the logic of createAtom. Can I ask a few
> questions?
>
> - Looks like we create both LayoutBefore and LayoutAfter references. Do we
> really need to create both? If A-layout-before-B is equivalent to
> B-layout-after-A it doesn't look necessary.
>
>  This is needed so that garbage collection wont remove the reference. If
> there is no atom thats referencing the current atom, that atom will be
> removed. So its needed for Atoms in a section to have both layout-after and
> layout-before.
>
> See the thread
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121022/154084.htmlfor more details on it.
>

I see. So, because all atoms in the same section (except weak symbols) are
reachable from each other, if there's a reference from a live atom to one
of them, all the other atoms in the same section (again, except weak ones)
become alive and will be emitted to the output binary. Is this
understanding correct?

 - The constraints and the reason that weak symbols need to satisfy about
> Reference are not very clear. Why are we handling weak symbols in such a
> way and how these References are handled in the later passes?
>
>  Weak references are tricky, that they can be overridden, so what we do is
> when there is a weak reference that contains some data, we create a weak
> atom followed by an anonymous atom that holds the data(Because of the same
> property that you want to keep everything in the ELF section). If the weak
> atom gets overridden you can safely remove the weak atom, since there is
> nothing that refers to (no layout before). Also another thing thats used is
> for example:
>
> An atom "A" is followed by a Weak atom(W). We create the three atoms A, W,
> W' (the atom that holds the data) and make A to be followed by W' and a
> back reference of layout before from W' to A. There is a bug that if there
> are two weak atoms one after another though, that some of the references
> are not created properly(I am going to fix that later).
>
> There are multiple tests (weak*.test), testing these scenarios.
>
> As you would have noticed, these are very critical for the final ELF image
> to work, in all cases.
>

Let me double check if I understand what you said by drawing a graph.
Normal arrow denotes Layout-After edge, and empty arrow denotes
Layout-Before edge. If a section has symbol A, W and C in this order, and W
is a weak symbol, then the resulting graph will look like this (Not sure
pasting a image will really work on this mailing list but let me try...):

[image: Inline image 1]

where W' is an anonymous atom having the content of W. If W is overridden
by a non-weak symbol, W will be GC'ed (dead-stripped) away, but its
contents will still be emitted to the resulting binary as W' is alive
(assuming A or C are alive), although there are no atoms that really refer
W's content. Is this correct?

And if there are two weak symbols, W1 and W2, between symbol A and C, then
the graph should become like this, right?

[image: Inline image 2]

 On Wed, Jun 5, 2013 at 2:52 PM, Rui Ueyama <ruiu at google.com>
<ruiu at google.com> wrote:
>
>
>  Hi shankarke,
>
>  - Split createAtom() in lib/ReaderWriter/ELF/File.h into small methods.
>  - Added comments to code in other methods.
>
> No functionality changes.
> http://llvm-reviews.chandlerc.com/D921
>
> Files:
>   lib/ReaderWriter/ELF/File.h
>   test/elf/X86_64/weak-override.test
>
>
>
>
> _______________________________________________
> llvm-commits mailing listllvm-commits at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130605/2a49d037/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: weak2.png
Type: image/png
Size: 13826 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130605/2a49d037/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: weak1.png
Type: image/png
Size: 7455 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130605/2a49d037/attachment-0001.png>


More information about the llvm-commits mailing list