<br><br><div class="gmail_quote">On Tue, Dec 13, 2011 at 9:27 PM, Rafael Ávila de Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>     $ llc bar.bc -filetype=obj -o bar.o<br>
>     $ clang -shared -o bar.so bar.o<br>
>     $ clang -use-gold-plugin foo.o bar.so -o t<br>
><br>
>     Is that correct? In particular, "lld t" should show a dependency on bar.<br>
>     Any particular reason for not adding this to the plugin api?<br>
><br>
> The result is a native .so here. My goal is to have a bitcode result.<br>
><br>
> gold plugin with mods supports that as well, but it would be nice to<br>
> avoid dependency on gold and gold plugin to simplify things.<br>
<br>
</div>Sorry, I meant equivalent only in the produced executable (t). In the<br>
above example the bar.bc is your "shared IL library" which I assume<br>
already exists. You want to produce a executable (t) which has a<br>
dependency on a shared library with the symbols defined in foo.bc.<br>
<br>
Is that the use case?<br></blockquote><div><br></div><div>Almost. The difference is that I want to have a bitcode module as the result of linking, not executable file. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> I believe that Emscripten does not use gold and gold plugin at the<br>
> moment. They use<br>
> llvm-link: <a href="https://github.com/kripken/emscripten/wiki/Building-Projects" target="_blank">https://github.com/kripken/emscripten/wiki/Building-Projects</a><br>
<br>
</div>I think that is the current implementation, yes.<br>
<div class="im"><br>
> I fully agree that all the features I want from the bitcode linker may<br>
> be achieved with gold + gold plugin (with mods to both parts), but I<br>
> would like to stay away from this dependency. Partly, because<br>
> maintaining modified gold and gold plugin is no fun, partly because gold<br>
> + gold plugin is hardly broken under cygwin.<br>
<br>
</div>I understand. I was just pointing that emacscriten case looks different<br>
from what you have. I don't see where an LLVM IL library (libc in your<br>
example) would fit. All that is needed is a stub with the functions that<br>
will be defined in JS in the end.<br></blockquote><div>bitcode "so" is supposed to have the form of:</div><div><br></div><div>define void @printf() {</div><div>  ret void</div><div>} </div><div>...</div><div><br>
</div><div>In this case, Empscripten might want to generate such stubs based on the list of javascript functions they provide and in my case, t<span style="background-color:transparent">he 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.</span></div>
<div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">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)</span></div>
<div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">Is it more clear now? If not, I would like to give it another try and write much more details and examples.</span></div>
<div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">krasin</span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br>