[LLVMdev] [RFC]Extending lib/Linker to support bitcode "shared objects"

Ivan Krasin krasin at google.com
Mon Dec 12 09:25:21 PST 2011

On Sun, Dec 11, 2011 at 2:19 PM, Rafael Ávila de Espíndola <
rafael.espindola at gmail.com> wrote:

> On 08/12/11 03:56 PM, Ivan Krasin wrote:
> > Hi llvm team!
> >
> > I'm currently working on the extended version of llvm-ld, which has an
> > ability to check if all the symbols present (and fail if some symbols
> > are not resolved), treat archives in the right way (link all the object
> > files in the archive if it's specified as the regular input, not as -l)
> Is that the "right way"? I think all native linker require a
> --whole-archive or similar to do that, no?
My mistake. Please, read the phrase as "support -whole-archive".

> > and the most important to my project feature: to link against bitcode
> > "shared objects". The semantics is pretty simple. The module treated as
> > shared object is only used as the source of symbol names which be
> > excluded from the list unresolved symbols.
> In summary, linking foo.bc and bar.bcso (do you use a different
> extension to differentiate from a "static" bc?) would be equivalent (but
> faster, easier) to
> $ llc bar.bc -filetype=obj -o bar.o
> $ clang -shared -o bar.so bar.o
> $ clang -use-gold-plugin foo.o bar.so -o t
> Is that correct? In particular, "lld t" should show a dependency on bar.
> Any particular reason for not adding this to the plugin api?
The result is a native .so here. My goal is to have a bitcode result.

gold plugin with mods supports that as well, but it would be nice to avoid
dependency on gold and gold plugin to simplify things.

> > I feel like the similar functionality might be useful for other projects
> > as well. For example, Emscripten (as of 3 months ago, when I have
> > checked it) does not check for undefined symbols at link time, because
> > it does not have a way to link against glibc (the symbols from which
> > would be added at runtime as usual javascript functions). This adds
> > additional overhead to the developer who ports the software to
> > javascript using Emscripten.
> Is that the same case? It seems that it would be easier to just include
> a stub ELF libc.so with the symbols from libc that Emscripten supports.
I believe that Emscripten does not use gold and gold plugin at the moment.
They use llvm-link:

I fully agree that all the features I want from the bitcode linker may be
achieved with gold + gold plugin (with mods to both parts), but I would
like to stay away from this dependency. Partly, because maintaining
modified gold and gold plugin is no fun, partly because gold + gold plugin
is hardly broken under cygwin. See
http://code.google.com/p/nativeclient/issues/detail?id=2286 for more
details. In short, it's because cygwin does not fully support dlopen.

It may be fixed by linking gold plugin to gold statically, like here:
http://codereview.chromium.org/8713008/ but it only adds the complexity.

> > Any objections? Comments?
> >
> > Ivan Krasin
> Cheers,
> Rafael
> _______________________________________________
> 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/20111212/86621978/attachment.html>

More information about the llvm-dev mailing list