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

Rafael Ávila de Espíndola rafael.espindola at gmail.com
Tue Dec 13 21:27:11 PST 2011


>     $ 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.

Sorry, I meant equivalent only in the produced executable (t). In the
above example the bar.bc is your "shared IL library" which I assume
already exists. You want to produce a executable (t) which has a
dependency on a shared library with the symbols defined in foo.bc.

Is that the use case?

> I believe that Emscripten does not use gold and gold plugin at the
> moment. They use
> llvm-link: https://github.com/kripken/emscripten/wiki/Building-Projects

I think that is the current implementation, yes.

> 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.

I understand. I was just pointing that emacscriten case looks different
from what you have. I don't see where an LLVM IL library (libc in your
example) would fit. All that is needed is a stub with the functions that
will be defined in JS in the end.

Cheers,
Rafael



More information about the llvm-dev mailing list