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

[Reid Kleckner]

You shouldn't need to use bitcode and opt -internalize to hide the
symbols.  You can do it with objcopy --localize-hidden like we did for
DynamoRIO, but I assume you prefer this route because it ports nicely
to Mac.  :)

On Tue, May 7, 2013 at 5: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
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev