[LLVMdev] RFC: Using zlib to decompress debug info sections.

[Evgeniy Stepanov]

This might be a bit late, but I've got another argument for bundling
zlib source with LLVM.

Sanitizer tools need to symbolize stack traces in the reports. We've
been using standalone symbolizer binary until now; sanitizer runtime
spawns a new process as soon as an error is found, and communicates
with it over a pipe. This is very cumbersome to deploy, because we
need to keep another binary around, specify a path to it at runtime,
etc. LLVM lit.cfg already carries some of this burden.

A much better solution would be to statically link symbolization code
into the user application, the same as sanitizer runtime library.
Unfortunately, symbolizer depends on several LLVM libraries, C++
runtime, zlib, etc. Statically linking all that stuff with user code
results in symbol name conflicts.

We've come up with what seems to be a perfect solution (thanks to a
Chandler's advice at the recent developer meeting). We build
everything down to (but not including) libc into LLVM bitcode. This
includes LLVMSupport, LLVMObject, LLVMDebugInfo, libc++, libc++abi,
zlib (!). Then we bundle it all together and internalize all
non-interface symbols: llvm-link && opt -internalize. Then compile
down to a single object file.

This results in a perfect isolation of symbolizer internals. One
drawback is that this requires source for all the things that I
mentioned - and at the moment we've got everything but zlib.

We'd like this to be a part of the normal LLVM build, but that
requires zlib source available somewhere. We could add a
cmake/configure option to point to an externally available source, but
that sounds like a complication we would like to avoid.

WDYT?


On Wed, Apr 17, 2013 at 5:02 PM, Alexey Samsonov <samsonov at google.com> wrote:
>
> On Wed, Apr 17, 2013 at 12:37 AM, Chris Lattner <clattner at apple.com> wrote:
>>
>> On Apr 16, 2013, at 11:53 AM, Eric Christopher <echristo at gmail.com> wrote:
>> > Historically we've done the former. The latter would require Chris
>> > wanting to do that.
>>
>> This case isn't so clearcut.  We like to include libraries in the source
>> to make it easy to get up and running without having to install a ton of
>> dependencies.  However, this has license implications and is generally
>> annoying.
>
>
> Looks like zlib license is good enough to avoid implications, but I can't
> really judge.
>>
>>
>> Given that zlib is so widely available by default, and that the compiler
>> can generate correct (albeit uncompressed) debug info, I think the best
>> thing is to *not* include a copy in llvm.  Just detect and use it if we can
>> find it, but otherwise generate uncompressed output.
>
>
> Sure, I'll go this way then. Thanks!
>
> --
> Alexey Samsonov, MSK
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>