<div dir="ltr"><div>What would be the valid values of scope ? <br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 15, 2014 at 9:01 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Aug 15, 2014, at 4:31 PM, Nick Kledzik <<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>> wrote:<br>
<br>
><br>
> On Aug 15, 2014, at 2:44 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>> wrote:<br>
><br>
>> On 8/15/2014 3:48 PM, Nick Kledzik wrote:<br>
>>> Good point.  Rather than a set <const DefinedAtom*>, ELFLinkingContext can just maintain<br>
>>> a StringSet.  That is, record the atom’s name instead of its address.  That approach would<br>
>>> not work for anonymous (unnamed) atoms or scopeTranslationUnit (static) atoms.  But in<br>
>>> this case, the atoms are named and scopeGlobal, so it will work.<br>
>> Nick,<br>
>><br>
>> I would prefer the data not saved in the LinkingContext as the whole information is lost on what data was dynamically exported when using --output-filetype=YAML.<br>
>><br>
>> The dynamic export functionality cannot be tested outside the Reader.<br>
>><br>
>> Having a reference type inbuilt into the linker would be much more useful, IMO.<br>
> Yes, having the info in the graph would be better than in a side table.<br>
><br>
> The problem is the nodes in the graph are read-only (expect for the target of edges (References)).<br>
><br>
> Yes, adding references is a standard technique for adding platform specific info to atoms.  But<br>
> that is usually done when the atom is created - not later.  In this case it is particularly cumbersome because either we need a way to add references to atoms or every atom must have an empty reference waiting for this use.  Then we still don’t have a way to modify that reference (only the target is modifiable).  And in this case using references is extra weird because there is already a DefinedAtom method dynamicExport() that already should return what we want.<br>

><br>
> Maybe we should just bite the bullet and add a setter to DefinedAtom:<br>
><br>
>    virtual void setDynamicExport(bool);<br>
><br>
> Update the subclasses of DefineAtom to handle this setter.<br>
> Then use const_cast<DefinedAtom*> to call it.<br>
><br>
> Since when setDynamicExport() should be called is platform specific, the Resolver still needs a call out to the context.  My previous idea of adding to LinkingContext:<br>
>       void validatedCoalesce(const Atom &existingAtom, const Atom &newAtom, bool &useNew);<br>
> still works for that.<br>
<br>
</div></div>I’m running into a very similar issue trying to implement -exported_symbols_list option.  I’m working on a patch to add a setScope() option to DefinedAtom.  I’ll post a patch for review Monday and see if we all think this is the way to go for these sorts of problems.<br>

<br>
-Nick<br>
<br>
</blockquote></div><br></div>