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

[Rafael Ávila de Espíndola]

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?

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

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

> Any objections? Comments?
> 
> Ivan Krasin

Cheers,
Rafael