[LLVMdev] [lld] Undefined symbols postprocessing

[Denis Protivensky]

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.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150219/e3ebf5ca/attachment.html>