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

Shankar Easwaran shankare at codeaurora.org
Tue Aug 19 15:29:18 PDT 2014


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.
>> 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




More information about the llvm-commits mailing list