[LLVMdev] [lld] Undefined symbols postprocessing

Shankar Easwaran shankare at codeaurora.org
Thu Feb 19 07:00:51 PST 2015


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




More information about the llvm-dev mailing list