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

[kledzik at apple.com]

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

================
Comment at: lib/ReaderWriter/Native/ReaderNative.cpp:888-894
@@ +887,9 @@
+
+inline void NativeDefinedAtomV1::setScope(DefinedAtom::Scope s) {
+  // Do nothing is scope is already requested value.
+  if (scope() == s)
+    return;
+  // Changing scope is rare.  Store changes in side table.
+  _file->_atomAttributeOverrides[this].scope = s;
+}
+
----------------
Shankar Kalpathi Easwaran wrote:
> Is this needed anytime ? What kind of usecase is this ?
This is to show that we can add setters to the NativeReader even though the native file is mapped read-only.  In the future if a flavor needs to use setters and someone stores a input file in native, we need the setters to work.

http://reviews.llvm.org/D4965