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

[Michael Spencer]

On Tue, Aug 19, 2014 at 3:57 PM, Rui Ueyama <ruiu at google.com> wrote:
> 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.

I agree with not having a side data structure that would have to be
checked on every access due to performance concerns. Mutating the
graph is fine, and we already do it with references.

- Michael Spencer

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