[LLVMdev] [lld] Undefined symbols postprocessing

[Nick Kledzik]

On Feb 23, 2015, at 2:52 PM, Michael Spencer <bigcheesegs at gmail.com> wrote:

> On Thu, Feb 19, 2015 at 10:40 PM, Denis Protivensky
> <dprotivensky at accesssoftek.com> wrote:
>> Shankar,
>> 
>> Okay, I guessed the correct interface.
>> But what about the moment at which the function is called?
>> If it's called from Resolver::resolve(), it doesn't make any difference to
>> me as I cannot determine the need of specific symbols at that time.
>> 
>> - Denis.
> 
> None of the symbols we are looking up require the full resolver, and
> they are all special linker symbols. I propose two things.
> 
> 1. Provide a hook as per what Shankar suggested for the resolver. User
> references to linker defined symbols such as _GLOBAL_OFFSET_TABLE_ get
> created and possibly deadstripped here. The linking context owns the
> atom.
> 2. The ELFLinkingContext gains <Atom
> *getOrCreateLinkerDefinedAtom(StringRef);>. This can be used in passes
> to get the symbols. The hook in (1) would call this to create the
> atoms.
> 
> This gives a single place where linker defined atoms are actually
> created, and allows correct deadstripping and object file references
> without doing multiple resolver passes.
As Rui showed, we already have this abstraction.  The linking context just adds a magic ArchiveFile.  When queried for any “linker defined symbol”, the magic ArchiveFile instantiates the atoms needed.

This is how mach-o handles linker defined symbols like __dso_handle.

-Nick


> 
>> 
>> 
>> On 02/19/2015 08:15 PM, Shankar Easwaran wrote:
>> 
>> + Nick
>> 
>> On 2/19/2015 9:00 AM, Shankar Easwaran wrote:
>>> On 2/19/2015 3:58 AM, Denis Protivensky wrote:
>>>> Joerg:
>>>>> I propose to add the ability to ignore undefined symbols during initial
>>>>> resolution, and then postprocess only those undefines for the second
>>>>> time
>>>>> after the pass manager execution.
>>>> Do you want to do that before or after dead code elimination?
>>>> I think dead code elimination should be performed after all possible
>>>> object code modifications done by lld. Therefore, it should be done
>>>> after undefines' postprocessing as well.
>>> Gnu does dead code elimination before undefines are reported. So if a
>>> function is not called and it has a undefined reference its would not
>>> be an undef.
>>>> 
>>>> Shankar:
>>>>> I propose to add the ability to ignore undefined symbols during initial
>>>>> resolution, and then postprocess only those undefines for the second
>>>>> time
>>>>> after the pass manager execution.
>>>> I came across this same problem, and was planning on adding a
>>>> notifyUndefinedSymbol to the LinkingContext, if the linker wants to add
>>>> a defined symbol and coalesce it, it would be possible.
>>>> 
>>>> Do you think this will work for your case too ?
>>>> With this option, I don't see:
>>>> - how to postpone processing and reaction on undefines. If the
>>>> callback is called from within Resolver::resolve(), you should react
>>>> on it immediately, because otherwise the code will still fail in
>>>> Resolver::resolve().
>>>> - how to know if a symbol is needed within the callback body. The
>>>> need of any symbol is determined in some other place. So I need to
>>>> keep a sort of indication (boolean flags, whatever) to know which
>>>> symbols are really needed.
>>>> - the exact interface of notifyUndefinedSymbol callback. If it
>>>> receives `StringRef` name of the undefined symbol, what reaction
>>>> should be? Should it return new symbols to add back to the caller as
>>>> `const Atom*`?
>>> notifyUndefinedSymbol will allow the context to coalesce the undefined
>>> atom with a defined atom.
>>> 
>>> Atom *notifyUndefinedSymbol(StringRef name) could be the interface.
>>> 
>>>> Thanks,
>>>>   Denis.
>>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
>> the Linux Foundation
>> 
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev