[PATCH] [ELF] LLD does not create a record in the .dynsym if a strong symbol defined in the executable file replaces a weak symbol from a shared library.

[Nick Kledzik]

On Aug 15, 2014, at 10:56 AM, Simon Atanasyan <simon at atanasyan.com> wrote:
> On Thu, Aug 14, 2014 at 11:08 PM, Nick Kledzik <kledzik at apple.com> wrote:
> 
> That was my original idea but I bumped into the "const" problem too.
> 
>> Shankar’s idea of adding a new Reference which the Resolver can tweak is way to side
>> step the const problem.  But it is a little clunky in that the Resolver needs to know
>> how to find this magic Reference and change it (which still needs a const_cast), and
>> dynamicExport() needs to be reworked to search for the magic Reference.
>> 
>> My suggestion is to add a new method to LinkingContext like:
>> 
>>  void validatedCoalesce(const Atom &existingAtom, const Atom &newAtom, bool &useNew);
>> 
>> Which is called at the end of SymbolTable::addByName() to give the platform specific
>> code a chance to either change which atom will be kept, or record side information. In your case
>> ELFLinkingContext could use this to maintain a set<const DefinedAtom*> which need
>> to be added to the dynsym table.
> 
> I like this idea but I am not sure that this approach can be used with RoundTripYAMLPass
> and RoundTripNativePass. As far as I understand references (suggested by Shankar) correctly
> survive YAML/Native conversions. But if we somehow store pointers to atoms in
> the validatedCoalesce() method these pointers will not be valid after
> the RoundTripNativePass finished.
Good point.  Rather than a set <const DefinedAtom*>, ELFLinkingContext can just maintain
a StringSet.  That is, record the atom’s name instead of its address.  That approach would
not work for anonymous (unnamed) atoms or scopeTranslationUnit (static) atoms.  But in
this case, the atoms are named and scopeGlobal, so it will work.

-Nick