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

Nick Kledzik kledzik at apple.com
Tue Aug 19 15:16:58 PDT 2014


On Aug 19, 2014, at 2:27 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:

> On 8/19/2014 2:08 PM, kledzik at apple.com wrote:
>> ================
>> Comment at: include/lld/Core/LinkingContext.h:230
>> @@ +229,3 @@
>> +  /// as adjusting the atom's scope.
>> +  virtual void notifySymbolTableAdd(const Atom *atom) const {
>> +  }
>> ----------------
>> Shankar Kalpathi Easwaran wrote:
>>> kledzik at apple.com wrote:
>>>> Rui Ueyama wrote:
>>>>> This function signature made me a bit sad because it's intended to mutate a given atom despite it takes const Atom *. We may probably want to make the atom graph mutable in the first place, because it's no longer actually const because of the addition of this function, so that we don't have to sprinkle const_casts in many places. I don't like to see that change in this CL but it may need to be considered later.
>>>> Yes. For now the graph is 99.9% const, so a few const_cast<> keeps it closer to what we are trying to model.  But if we have Passes that need to modify atoms, or lots of places need start modifying atoms, it will probably make sense to remove the const in the zillion places.
>>> Various flavors can go over the atoms in pass and set the appropriate attributes right, Am I missing something ? Same with the below function as well.
>> Shankar,  Passes are run after resolving is done. So a Pass cannot tell, for instance, that a DefineAtom replaced a weak SharedLibraryAtom (which for ELF means the DefinedAtom should be dynamicExport).  These hooks give the flavor's LinkingContext a change to record such flavor specific info.
>> 
>> ================
>> Comment at: lib/Core/DefinedAtom.cpp:86
>> @@ -83,1 +85,3 @@
>>  
>> +void DefinedAtom::setScope(Scope s) {
>> +  assert(s == scope() && "setScope() must be overridden to alter scope");
>> ----------------
>> Shankar Kalpathi Easwaran wrote:
>>> I think visibility and scope are being mixed. While scope needs to be a property of the atom, I am not convinced visibility has to be part of the Atom has well, as visibility is mostly user driven.
>> What do you mean by "visibility"?  The lld model does not have a visibility concept.
>> 
>> The ELF file format started with just two levels of scope (STB_LOCAL and STB_GLOBAL).  Later the middle level of scope (linkage unit) was invented, for ELF it is represented as STB_GLOBAL plus  STV_HIDDEN on the side.
> 
> 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. 

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

-Nick






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140819/4e9efd80/attachment.html>


More information about the llvm-commits mailing list