[PATCH] [lld] Proposal and example for changing Atom attributes.

Rui Ueyama ruiu at google.com
Tue Aug 19 15:57:17 PDT 2014


On Tue, Aug 19, 2014 at 3:29 PM, Shankar Easwaran <shankare at codeaurora.org>
wrote:

> On 8/19/2014 5:16 PM, Nick Kledzik wrote:
>
>> ELF has the concept of bindiing and visibility.
>>
>> Binding can be STB_LOCAL, STB_GLOBAL, STB_WEAK which could be modeled
>> using scope.
>>
>> Visibility plays a role mainly in dynamic linking (executables and
>> dynamic libraries).  Common examples of visibility are STV_DEFAULT. There
>> are other variants of visibility STV_HIDDEN, STV_PROTECTED, STV_INTERNAL.
>>
>> <snip from ELF abi for convenience>
>>
>> The ELF application binary interface (ABI) defines the visibility of
>> symbols. Generally, it defines four classes, but in most cases, only two of
>> them are more commonly used:
>> STV_DEFAULT - Symbols defined with it will be exported. In other words,
>> it declares that symbols are visible everywhere.
>> STV_HIDDEN - Symbols defined with it will not be exported and cannot be
>> used from other objects.
>> STV_PROTECTED: The symbol is visible outside the current executable or
>> shared object, but it may not be overridden. In other words, if a protected
>> symbol in a shared library is referenced by an other code in the shared
>> library, the other code will always reference the symbol in the shared
>> library, even if the executable defines a symbol with the same name.
>> STV_INTERNAL: The symbol is not accessible outside the current executable
>> or shared library.
>> </end snip>
>>
>> The main problem I see with the setScope function from when called from a
>> callback function is, the atom loses the original property of how it
>> appeared in the object file.
>> Yes.  That is the big model change here.  Previously, the atoms were
>> always read-only.  Now we are saying Passes and the LinkingContext may
>> modify the atoms as the linking progresses.  The goal being that by the end
>> of the link, the atoms reflect what the Writer needs.  If we don’t allow
>> this, then we need to invent some sidecar somewhere which tracks the extra
>> information Writers need.
>>
> I think a sidecar model would be more beneficial here, Just my $0.02.
>
> If we need something in the future its easier to add to the sidecar,
> rather than changing/looking for an attribute in the Atoms.
>
> References are one way to record that information, I was thinking if we
> have a key value pair of recognized keys and values it might be easier to
> look for as well.


The reference is not a sidecar; it's a part of the graph (edge). Along with
the atom (vertex) it consists the entire graph. By sidecar, I guess Nick
suggested having a completely separate data structure than the graph. I
basically agree with Nick that maintaining such information besides the
graph is going to be complicated. It would annotate the graph (in that
sense it's logically mutate the graph) while we wouldn't actually mutate
the graph. Maybe we should aggregate the information in one place, which is
the graph.

 If we decide that the Atom is not needed to be exported, the linker could
>>> set the visibility attribute to HIDDEN/PROTECTED, but still my original
>>> question remains that the NativeAtoms will not model how it originally
>>> appeared in the object file.
>>>
>> Are you concerned that full ELF symbol bits cannot survive a round trip
>> through the Atom model (nothing about his patch changes that)?  Or that
>> something about the NativeAtom format?  Or that the original state of any
>> atom is lost by adding setters?
>>
>
> The concern I have is
>
> * debugging on whether there was a bug in the reader / something because
> of the set methods that changed the state of the atom.
> * if someday lld allows the native file to be read by the linker, the
> original property of the atoms would no longer be there for examination.
>
> Shankar Easwaran
>
> --
> 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/20140819/126c1da2/attachment.html>


More information about the llvm-commits mailing list