[LLVMdev] [lld] Undefined symbols postprocessing

Denis Protivensky dprotivensky at accesssoftek.com
Thu Feb 19 01:58:59 PST 2015


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.

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*`?

Thanks,
  Denis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150219/9a5c09dc/attachment.html>


More information about the llvm-dev mailing list