Hi, tl;dr How can I include LLVM headers and use code from libLLVM*.a files when building compiler-rt libraries? I'd like to create a symbolizer that would be used in AddressSanitizer (ASan) and ThreadSanitizer (TSan) tools which are now part of projects/compiler-rt (as a first step, symbolizer should be able to return file/line info for a given address). I'd like to use and gradually extend the interface in "llvm/DebugInfo/DIContext.h" I see two obstacles: 1) How can I include LLVM headers in source files inside projects/compiler-rt? As a local workaround, I modify configuration for ASan/TSan runtimes as follows: CFLAGS.asan-x86_64 := $(CFLAGS) -I$(PathToLLVMInclude) -I$(PathToLLVMBuildInclude) Note that I need both "/path/to/llvm_checkout/include" and "/path/to/llvm_build/include", because some LLVM headers are generated when LLVM is built (e.g. "llvm/Support/DataTypes.h"). This looks very broken, as paths are hardcoded, and LLVM headers are not included in dependencies for ASan/TSan runtime. 2) How can I use LLVM libraries when building compiler-rt? Currently, compiler-rt builds (linux) runtime and stores it as an .a file in "/path/to/llvm_build/Release+Asserts/lib/clang/3.2/linux". Can I somehow make this runtime contain compiled LLVM libraries as well? Currently I need libLLVMDebugInfo.a and libLLVMSupport.a. For now, I patch Clang driver, so that it would pass all the necessary LLVM libraries to linker whenever it sees -faddress-sanitizer or -fthread-sanitizer flags, but this also looks hacky. TIA -- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120531/fcd61dab/attachment.html>
On Thu, May 31, 2012 at 2:02 AM, Alexey Samsonov <samsonov at google.com>wrote:> Hi, > > tl;dr How can I include LLVM headers and use code from libLLVM*.a files > when building compiler-rt libraries? >Currently, there isn't a way, but this is something I very much want to see supported. I started working on this w/ the CMake build system, but had to go work on other things. I do hope to get back to it, and if this is on the critical path, I can try to talk you through what needs to be done and review patches. I may even have some time to work on it soon. I'd like to create a symbolizer that would be used in AddressSanitizer> (ASan) and ThreadSanitizer (TSan) tools which are now part of > projects/compiler-rt (as a first step, symbolizer should be able to return > file/line info for a given address). > I'd like to use and gradually extend the interface in > "llvm/DebugInfo/DIContext.h" >I've discussed this with several others before (including Chris IIRC), and he strongly agreed with this approach FWIW.> I see two obstacles: > > 1) How can I include LLVM headers in source files inside > projects/compiler-rt? > As a local workaround, I modify configuration for ASan/TSan runtimes as > follows: > CFLAGS.asan-x86_64 := $(CFLAGS) -I$(PathToLLVMInclude) > -I$(PathToLLVMBuildInclude) > Note that I need both "/path/to/llvm_checkout/include" and > "/path/to/llvm_build/include", because some LLVM headers are generated when > LLVM is built (e.g. "llvm/Support/DataTypes.h"). This looks very broken, > as paths are hardcoded, and LLVM headers are > not included in dependencies for ASan/TSan runtime. >The CMake build system should make much of this Just Work by building the runtime as just another LLVM sub-project. I increasingly think this is the correct approach rather than trying to bootstrap the runtime library (despite being firmly on the other side of things originally). It simplifies a large number of issues, and I think all of my prior concerns were misplaced. I'm not an expert in the Makefile build system, but my suspicion is that the changes needed to get into the same position as the (rudimentary, and incomplete) CMake build support is to switch compiler-rt, and especially the *san libraries, to use the normal LLVM-subproject build system structure. However, the current Makefile build for compiler-rt has a huge special feature that won't play nicely with this: automatic cross-compilation. In order to make this *really* work, in either the Makefile or CMake build systems, we're going to have to teach the root LLVM build system how to do on-demand cross-compilation of selected LLVM libraries, so that compiler-rt can build a collection of libraries for different target platforms. From my perspective, that's the big hurdle. It's also likely to be quite a bit of work to figure out in either CMake or Makefiles, and I'm only really competent with the CMake side of things....> 2) How can I use LLVM libraries when building compiler-rt? > Currently, compiler-rt builds (linux) runtime and stores it as an .a file > in "/path/to/llvm_build/Release+Asserts/lib/clang/3.2/linux". > Can I somehow make this runtime contain compiled LLVM libraries as well? > Currently I need libLLVMDebugInfo.a and libLLVMSupport.a. >This shouldn't be a hard problem to solve at the build system level once you can compile against the libraries. You just have to re-run ar to fuse the archives. Let's solve this if & when we get the other solved. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120531/00e7cc3a/attachment.html>
On 31 May 2012 05:02, Alexey Samsonov <samsonov at google.com> wrote:> Hi, > > tl;dr How can I include LLVM headers and use code from libLLVM*.a files when > building compiler-rt libraries?LLVM and compiler-rt have different licenses (compiler-rt is dual licensed with the MIT license). Would that be a problem?> > TIA >Cheers, Rafael
On Thu, May 31, 2012 at 1:13 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> On 31 May 2012 05:02, Alexey Samsonov <samsonov at google.com> wrote: > > Hi, > > > > tl;dr How can I include LLVM headers and use code from libLLVM*.a files > when > > building compiler-rt libraries? > > LLVM and compiler-rt have different licenses (compiler-rt is dual > licensed with the MIT license). Would that be a problem? >This is a good point... Chris, I'm wondering whether putting all of the runtimes into 'compiler-rt' is really the best structure at this point... What would seem a somewhat less awkward fit to me these days: - a runtimes project which contains various runtime libraries, under the usual LLVM license - the original 'compiler-rt' bits either as a sub-library of this which happens to be buildable stand-alone and dual-licensed, or as its own entirely separate project - coverage profile runtime, asan, tsan, and common runtime libraries separated out from compiler-rt We can achieve the same technical result with the current structure, but its inverted and awkward: the restrictive rules (dual license / stand-alone build) are enforced in an outer layer, with the permissive rules returning in an inner layer (the asan or tsan runtimes themselves). Thoughts? If this is the direction to go, I'm happy to do the lion share of leg work to re-organize (with the help of ASan folks)... I think my personal preference would be for compiler-rt to be a separate top-level project from a generic 'runtimes' project. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120531/23ce8fd4/attachment.html>