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

[Ivan Krasin]

On Tue, Dec 13, 2011 at 9:27 PM, Rafael Ávila de Espíndola <
rafael.espindola at gmail.com> wrote:

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

Almost. The difference is that I want to have a bitcode module as the
result of linking, not executable file.

>
> > 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.
>
bitcode "so" is supposed to have the form of:

define void @printf() {
  ret void
}
...

In this case, Empscripten might want to generate such stubs based on the
list of javascript functions they provide and in my case, the generation of
this LL stub is a simple script based on nm, sed and llvm-as that takes
native .so as the input and produces a bitcode file with stub definitions
of the public symbols.

This is about the same use case as Emscripten with the only difference in
the source of the defined symbols (native .so vs js file)

Is it more clear now? If not, I would like to give it another try and write
much more details and examples.

krasin

>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111213/3a3af8c9/attachment.html>