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

[Shankar Easwaran]

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.

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.

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