[LLVMdev] [lld] Undefined symbols postprocessing

[Michael Spencer]

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.

- Michael Spencer

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