[LLVMdev] [lld] Undefined symbols postprocessing

[Shankar Easwaran]

On 2/18/2015 3:38 AM, Denis Protivensky wrote:
> Hi everyone,
>
> In lld, I need to conditionally add symbols (like GLOBAL_OFFSET_TABLE)
> during
> static linking because they may be used by relocations (R_ARM_TLS_IE32) or
> by some other stuff like STT_GNU_IFUNC symbols.
> The problem is that now symbols are added in a declarative way by
> specifying in ExecutableWriter::addDefaultAtoms() override.
> At that stage, there's no way to determine if additional symbols are
> required.
> But libraries providing optimizations like STT_GNU_IFUNC
> (glibc, for example) expect the GOT symbol to be defined, so the linking
> process
> fails in Resolver::resolve() if the symbol is not found.
>
> 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 ?

>
> Technically, this shouldn't be a problem:
> - there will be a new option in the linking context that should signal
> that the postprocessing of undefined symbols should be performed.
> - if postprocessing option is set, newly added symbols will be collected
> in the MergedFile returned by the Resolver, and then only those new symbols
> will take part in the resolution process very similar to what
> Resolver::resolve() does.
> - available implementations will not break and keep working without use of
> postprocessing feature.
>
> So my proposal is to move from the declarative style towards imperative
> and more flexible approach. Of course, there's a downside as the code
> loses some of its regularity and becomes more volatile, but in the end -
> we have tests to cover such things and ensure everything works as expected.
>
> Any ideas?
>
> - Denis Protivensky.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation