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

[Ivan Krasin]

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) 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. For example:

foo.c:

int main(void) {
  return bar()
}

bar.c:

int bar() {
  return 123;
}

In the native case, you have three options to link these files.

1. Classic static linking:

$ clang foo.c bar.c


2. Static linking with the archive.

$ clang -c bar.c
$ ar q libbar.a bar.o
$ clang foo.c -lbar -L.


3. Dynamic linking:

$ clang -c foo.c
$ clang -shared bar.c -o libbar.so
$ clang foo.c -lbar -L.
$ nm a.out
...
U bar
...
==========================================


Currently, lib/Linker supports first two cases, but not the third. I would
like to be able add this functionality and it even exists as the prototype:
https://github.com/krasin/bitlink
To build, just place it under llvm/tools and register in
tools/CMakefiles.txt

The utility itself is probably not interesting, because it's just a
modified llvm-ld. At the same time, it uses lib/Linker with the added
capability of dynamic linking with bitcode stubs:

$ clang -emit-llvm -c foo.c
clang -emit-llvm -c bar.c -o libbar.o

# Fail if there're undefined symbols:
$ bin/llvm-bitlink foo.o
llvm-bitlink: undefined reference to bar
llvm-bitlink: Linker aborted due to undefined symbols

# Add bitcode "shared object" and link against it:
$ bin/llvm-bitlink foo.o -shared-library bar.o

Check a.out.ll:
$ llvm-dis a.out
$ cat a.out.ll
...
define i32 @main(i32 %argc, i8** nocapture %argv) nounwind uwtable {
entry:
  %call = call i32 (...)* @bar() nounwind
  ret i32 %call
}

declare i32 @bar(...)
==========================================


I know, it's a basic example and it's not anyhow impressive, but hopefully
it provides the clue what I'm talking about. Our plans include generating
bitcode link-time stubs for glibc and doing the pure bitcode linking for
PNaCl.
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.

Any objections? Comments?

Ivan Krasin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111208/d4e7f914/attachment.html>