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

[Chandler Carruth]

Lemme chat with Danny off list about the best way to do this, and I'll post
an update.


On Tue, May 7, 2013 at 11:24 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com
> wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130507/68da2c38/attachment.html>