[LLVMdev] [lld] Undefined symbols postprocessing

[Rui Ueyama]

On Wed, Feb 18, 2015 at 1:38 AM, Denis Protivensky <
dprotivensky at accesssoftek.com> 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 don't know if this is directly applicable to your problem, but for
PE/COFF I needed to add symbols conditionally. If you have a function
*func* and
if there's a reference to __imp_*func*, linker needs to create a data
containing the address of func as __imp_func content. It's rarely used, so
I wanted to create the __imp_ atom only when there's an unresolved
reference to that symbol.

What I did at that moment is to define a (virtual) library file which
dynamically creates an atom. The virtual library file is added at end of
the input file list, and if the core linker looks it up for a symbol
starting __imp_, the library creates an object file containing the symbol
on the fly and returns it.

My experience of doing that is that worked but might have been too tricky.
If this trick is directly applicable to your problem, you may want to do
that. If not, I'm perhaps okay with your suggestion (although I didn't
think about that hard yet.)

Thanks


> 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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150219/26bbdc98/attachment.html>