search for: llvmdebuginfo

Hi everyone, I'm working on a library for runtime introspection of C++ programs, for example, getting stack traces, decorating logs with source file information, etc. It currently uses LLVMObject and LLVMDebugInfo. There's a feature I want to add, but it requires that I understand where on the stack local variables are located. For this to work on x86-64, I would need to do whole "virtual unwinding" thing, i.e., create a library that can understand the DWARF call frame information. This is so...

Reviving the discussion. The cool cmake-build of compiler-rt is not completely functional, but allows sanitizer runtimes to reuse LLVM code with almost no dirty hacks. Suppose I want to run call functions from LLVM libs (currently: LLVMDebugInfo, LLVMSupport) from sanitizer runtime. 1) I can simply include LLVM headers in sanitizer runtime, and it compiles and builds static asan runtime perfectly (wow). 2) Now building and running ASan unittests is simple - you just have to add a couple of lines to CMakeLists. target_link_librarie...

...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 t...

On Thu, Jun 21, 2012 at 1:44 PM, Chandler Carruth <chandlerc at google.com>wrote: > Can we alter the build system so that when building a run-time library it >>>>>>>> modifies all .cpp files like this: >>>>>>>> namespace FOO { >>>>>>>> <file body> >>>>>>>> }

...; 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 t...

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

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