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

[Ivan Krasin]

On Wed, Dec 14, 2011 at 10:38 AM, Rafael Ávila de Espíndola <
rafael.espindola at gmail.com> wrote:

> > Is it more clear now? If not, I would like to give it another try and
> > write much more details and examples.
>
> I am still not completely sure I understand the use case. In particular
> since you say you want a bitcode module in the end, I don't understand
> how this is different from using llvm-link, it doesn't complain about
> undefined symbols...
>
Complaining about undefined symbols is the next step. It's already
implemented in my branch:
https://github.com/krasin/bitlink/commit/be222a2863a989666d4925e5344d0c84cac8e06b


>
> Can you provide an example? What are your inputs. Are they IL or ELF?
> What are the outputs that you want? Are they IL or ELF?
>
All the inputs and all the outputs are IL. Some IL inputs are just stubs
which have only functions with empty bodies.
The output IL file is supposed to have all the symbols resolved, statically
or dynamically (i.e. there's a stub that has that symbols defined).
In case of Emscripten, that's enough.
In our case (PNaCl), we also add metadata to the output IL file, so that it
would be possible to track which shared libraries are actually needed.

As for "real life" example, we may want to consider a developer on Windows
machine who wants to write a portable program (that will run inside NaCl)
using libpng and glibc using PNaCl toolchain that would provide portable
bitcode stubs for glibc and libpng port from naclports repositories (with
link-time portable stubs as well). In this case, the developer wants to
create a bitcode file that will be treated by PNaCl as executable (and
would be translated to the target architecture before the actual run),
linked dynamically with glibc and libpng. He may achieve this by using
modified gold + modified gold plugin from the PNaCl toolchain (but Windows
would prevent him from this path, see cygwin notes in my previous
messages), or he can use the bitcode linker, I'm currently working on. In
this case, the developer will know if all the symbols are resolved and will
not have a dependency on gold linker.




>
> > krasin
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111215/06e8108d/attachment.html>