llvm dev - Apr 2013 - [LLVMdev] RFC: Using zlib to decompress debug info sections.

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.

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.

-Chris

On Tue, Apr 16, 2013 at 1:37 PM, 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.
>
> 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.
>
Sounds good to me. Thanks Chris!

-eric

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 <http://zlib.net/zlib_license.html> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130417/6ef7a7b7/attachment.html>

On Tue, Apr 16, 2013 at 01:37:18PM -0700, Chris Lattner
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.
>From a security perspective, bundling libraries that had issues in the
past and are not unlikely to have new issues in the future, it is highly
annoying. As such, I would strongly prefer to keep it optional.

Joerg

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
>