<div dir="ltr">Lemme chat with Danny off list about the best way to do this, and I'll post an update.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 7, 2013 at 11:24 AM, Evgeniy Stepanov <span dir="ltr"><<a href="mailto:eugeni.stepanov@gmail.com" target="_blank" class="cremed">eugeni.stepanov@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This might be a bit late, but I've got another argument for bundling<br>
zlib source with LLVM.<br>
<br>
Sanitizer tools need to symbolize stack traces in the reports. We've<br>
been using standalone symbolizer binary until now; sanitizer runtime<br>
spawns a new process as soon as an error is found, and communicates<br>
with it over a pipe. This is very cumbersome to deploy, because we<br>
need to keep another binary around, specify a path to it at runtime,<br>
etc. LLVM lit.cfg already carries some of this burden.<br>
<br>
A much better solution would be to statically link symbolization code<br>
into the user application, the same as sanitizer runtime library.<br>
Unfortunately, symbolizer depends on several LLVM libraries, C++<br>
runtime, zlib, etc. Statically linking all that stuff with user code<br>
results in symbol name conflicts.<br>
<br>
We've come up with what seems to be a perfect solution (thanks to a<br>
Chandler's advice at the recent developer meeting). We build<br>
everything down to (but not including) libc into LLVM bitcode. This<br>
includes LLVMSupport, LLVMObject, LLVMDebugInfo, libc++, libc++abi,<br>
zlib (!). Then we bundle it all together and internalize all<br>
non-interface symbols: llvm-link && opt -internalize. Then compile<br>
down to a single object file.<br>
<br>
This results in a perfect isolation of symbolizer internals. One<br>
drawback is that this requires source for all the things that I<br>
mentioned - and at the moment we've got everything but zlib.<br>
<br>
We'd like this to be a part of the normal LLVM build, but that<br>
requires zlib source available somewhere. We could add a<br>
cmake/configure option to point to an externally available source, but<br>
that sounds like a complication we would like to avoid.<br>
<br>
WDYT?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, Apr 17, 2013 at 5:02 PM, Alexey Samsonov <<a href="mailto:samsonov@google.com" class="cremed">samsonov@google.com</a>> wrote:<br>
><br>
> On Wed, Apr 17, 2013 at 12:37 AM, Chris Lattner <<a href="mailto:clattner@apple.com" class="cremed">clattner@apple.com</a>> wrote:<br>
>><br>
>> On Apr 16, 2013, at 11:53 AM, Eric Christopher <<a href="mailto:echristo@gmail.com" class="cremed">echristo@gmail.com</a>> wrote:<br>
>> > Historically we've done the former. The latter would require Chris<br>
>> > wanting to do that.<br>
>><br>
>> This case isn't so clearcut.  We like to include libraries in the source<br>
>> to make it easy to get up and running without having to install a ton of<br>
>> dependencies.  However, this has license implications and is generally<br>
>> annoying.<br>
><br>
><br>
> Looks like zlib license is good enough to avoid implications, but I can't<br>
> really judge.<br>
>><br>
>><br>
>> Given that zlib is so widely available by default, and that the compiler<br>
>> can generate correct (albeit uncompressed) debug info, I think the best<br>
>> thing is to *not* include a copy in llvm.  Just detect and use it if we can<br>
>> find it, but otherwise generate uncompressed output.<br>
><br>
><br>
> Sure, I'll go this way then. Thanks!<br>
><br>
> --<br>
> Alexey Samsonov, MSK<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" class="cremed">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank" class="cremed">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
</div></div></blockquote></div><br></div></div>