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

Displaying 20 results from an estimated 400 matches similar to: "[LLVMdev] RFC: Using zlib to decompress debug info sections."

2013 Apr 16
2
[LLVMdev] RFC: Using zlib to decompress debug info sections.
On Tue, Apr 16, 2013 at 8:31 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Tue, Apr 16, 2013 at 2:37 AM, Alexey Samsonov <samsonov at google.com>wrote: > >> Hi! >> >> TL;DR WDYT of adding zlib decompression capabilities to LLVMObject >> library? >> > >> ld.gold from GNU binutils has --compress-debug-sections=zlib option,
2013 Apr 16
0
[LLVMdev] RFC: Using zlib to decompress debug info sections.
On Tue, Apr 16, 2013 at 2:37 AM, Alexey Samsonov <samsonov at google.com>wrote: > Hi! > > TL;DR WDYT of adding zlib decompression capabilities to LLVMObject library? > > ld.gold from GNU binutils has --compress-debug-sections=zlib option, > which uses zlib to compress .debug_xxx sections and renames them to > .zdebug_xxx. > binutils (and GDB) support this properly,
2013 Apr 16
0
[LLVMdev] RFC: Using zlib to decompress debug info sections.
On Tue, Apr 16, 2013 at 9:37 AM, Alexey Samsonov <samsonov at google.com> wrote: > > On Tue, Apr 16, 2013 at 8:31 PM, Michael Spencer <bigcheesegs at gmail.com> > wrote: >> >> On Tue, Apr 16, 2013 at 2:37 AM, Alexey Samsonov <samsonov at google.com> >> wrote: >>> >>> Hi! >>> >>> TL;DR WDYT of adding zlib decompression
2013 Apr 16
2
[LLVMdev] RFC: Using zlib to decompress debug info sections.
Just in case - do we want to link with libz.so installed in the system, or be self-contained and copy sources to LLVM repo? On Tue, Apr 16, 2013 at 10:48 PM, Eric Christopher <echristo at gmail.com>wrote: > On Tue, Apr 16, 2013 at 9:37 AM, Alexey Samsonov <samsonov at google.com> > wrote: > > > > On Tue, Apr 16, 2013 at 8:31 PM, Michael Spencer <bigcheesegs at
2013 Apr 16
0
[LLVMdev] RFC: Using zlib to decompress debug info sections.
Historically we've done the former. The latter would require Chris wanting to do that. -eric On Tue, Apr 16, 2013 at 11:52 AM, Alexey Samsonov <samsonov at google.com> wrote: > Just in case - do we want to link with libz.so installed in the system, or > be self-contained and copy sources to LLVM repo? > > > On Tue, Apr 16, 2013 at 10:48 PM, Eric Christopher <echristo
2018 Feb 08
2
LLD: targeting cygwin
Here are the linker errors: lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_end__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_end__ lld: warning:
2018 Feb 09
0
LLD: targeting cygwin
Is that the only problem to use lld to link cygwin programs? On Thu, Feb 8, 2018 at 8:19 AM, Andrew Kelley <superjoe30 at gmail.com> wrote: > Here are the linker errors: > > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_start__ > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_end__ > lld: warning:
2018 Feb 07
0
LLD: targeting cygwin
COFF lld doesn't support the linker script at the moment, and I'm sad to say that it is very unlikely to support that in the future. Linker script support is so huge that I can't imagine we really want it for COFF. GNU BFD linker supports it because the linker is built as an interpreter for the built-in linker script (and that's one of the reasons why GNU linker is by far more
2018 Feb 07
2
LLD: targeting cygwin
Hello, I have a user who is trying to get LLD to link for the cygwin target: https://github.com/zig-lang/zig/issues/751 Currently the issue they are running into is needing to define a linker script, but the COFF driver (or MinGW driver) does not have support for that. Is there documentation or advice for how to use LLD to link for cygwin? As a starting point, which driver to use? Regards,
2016 May 24
2
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: > Jack, > > What version of CMake are you using? > > -Chris Chris, I am using cmake 3.5.2. My read of this problem is as follows. While libLLVM.dylib is being linked against -lxar when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib is created with -Wl,-dead_strip such that
2016 May 24
0
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
On Tue, May 24, 2016 at 2:37 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >> Jack, >> >> What version of CMake are you using? >> >> -Chris > > Chris, > I am using cmake 3.5.2. My read of this problem is as follows. > While libLLVM.dylib is
2013 May 07
4
[LLVMdev] RFC: Using zlib to decompress debug info sections.
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
2016 May 24
1
Undefined symbols in llvm-objdump linkage on x86_64-apple-darwin15
On Tue, May 24, 2016 at 3:03 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:37 PM, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: >> On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >>> Jack, >>> >>> What version of CMake are you using? >>> >>>
2020 Apr 23
7
Cannot build master
Hi, Using master at b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8, I cannot build LLVM. I configured with: CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_BUILD_LLVM_DYLIB=ON \ -DLLVM_LINK_LLVM_DYLIB=ON \ -DBUILD_SHARED_LIBS=OFF \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \
2017 Sep 08
8
[RFC] Open sourcing and contributing TAPI back to the LLVM community
Hi @ll, Over the past years I have been looking into how to reduce the size of the SDK that ships with Xcode and how to improve build times for the overall OS inside Apple. The result is a tool called TAPI, which is used at Apple for all things related to text-based dynamic library files (.tbd). What are text-based dynamic library files? Text-based dynamic library files (TBDs) are a textual
2013 May 07
0
[LLVMdev] RFC: Using zlib to decompress debug info sections.
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 >
2013 Apr 17
0
[LLVMdev] RFC: Using zlib to decompress debug info sections.
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
2017 Feb 21
2
tooling libraries missing in Windows download
I was looking to write a cross platform utility that worked with ELF/DWARF files. I need the utility to run on OS X, Linux and Windows. I figured I could use clang/llvm to build this tool. I've made good progress on OS X. Before I got too far, though. I decided to verify that I can build the code on Windows. I downloaded the 3.8.0 Windows installer from the llvm downwloads page, ran the
2013 Apr 16
4
[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
2015 Jun 19
4
[LLVMdev] [CMake] Generated LLVMConfig.cmake and LLVMExports.cmake broken under Visual Studio 2015
On 06/18/2015 06:46 PM, Dan Liew wrote: >> The issue is the that that generated LLVMExports.cmake file has this in it >> INTERFACE_LINK_LIBRARIES "LLVMObject;LLVMSupport;C:\Program Files (x86)\Microsoft Visual Studio 14.0\DIA SDK\lib\diaguids.lib" > > Hmm actually this might be a bug in the > ``/lib/DebugInfo/PDB/CMakeLists.txt`` file. CC'ing Zach Turner seeing