Talin
2011-Jun-25 05:51 UTC
[LLVMdev] Segfault calling LLVM libs from a clang-compiled executable
A couple of months ago, I started the process of updating my CMake scripts to allow my compiler to be compiled with clang. I quickly ran into a problem calling the LLVM libraries, which is that I would get segfaults when calling LLVM API functions. I posted about this on both the clang and llvm-dev lists, but there was no response, so I decided to put the clang-related work on hold. Last week I decided to pick this up again. My motivation for doing so is that it's much easier to work with clang's error diagnostics, and coding is generally more productive. However, I once again observed the same problem, which I will now attempt to describe in some detail: I start with a fresh checkout of both llvm and clang. Both get compiled with gcc (this is on the most recent version of Ubuntu, 64-bit although I've seen the same problem on other OS configurations.) Then I compile my compiler with clang, and link it against the llvm libs. Everything works fine up to a point - that is, I'm able to use all of the ADT classes, derived types, and so on - until I get into the code generation phase, at which point things blow up. Specifically, I get a segfault in DIBuilder::createPointerType() (well, actually the segfault is several stack levels down from that.) Looking in gdb, it appears that there is some sort of calling convention mismatch - my code is calling createPointerType() with an empty StringRef(), but when I attempt to look at the StringRef argument from within the createPointerType() function, the field values are garbage. This is exactly at the point where execution is transitioning from clang-compiled code to gcc-compiled code. If I instead compile my frontend with gcc, everything works fine. If you want to see what command-line flags I'm passing to clang, here's what my CMakeLists.txt looks like: http://code.google.com/p/tart/source/browse/trunk/CMakeLists.txt#156 -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110624/baf0579a/attachment.html>
Eli Friedman
2011-Jun-25 08:34 UTC
[LLVMdev] Segfault calling LLVM libs from a clang-compiled executable
On Fri, Jun 24, 2011 at 10:51 PM, Talin <viridia at gmail.com> wrote:> A couple of months ago, I started the process of updating my CMake scripts > to allow my compiler to be compiled with clang. I quickly ran into a problem > calling the LLVM libraries, which is that I would get segfaults when calling > LLVM API functions. I posted about this on both the clang and llvm-dev > lists, but there was no response, so I decided to put the clang-related work > on hold. > Last week I decided to pick this up again. My motivation for doing so is > that it's much easier to work with clang's error diagnostics, and coding is > generally more productive. However, I once again observed the same problem, > which I will now attempt to describe in some detail: > I start with a fresh checkout of both llvm and clang. Both get compiled with > gcc (this is on the most recent version of Ubuntu, 64-bit although I've seen > the same problem on other OS configurations.) Then I compile my compiler > with clang, and link it against the llvm libs. Everything works fine up to a > point - that is, I'm able to use all of the ADT classes, derived types, and > so on - until I get into the code generation phase, at which point things > blow up. Specifically, I get a segfault in DIBuilder::createPointerType() > (well, actually the segfault is several stack levels down from that.) > Looking in gdb, it appears that there is some sort of calling convention > mismatch - my code is calling createPointerType() with an empty StringRef(), > but when I attempt to look at the StringRef argument from within the > createPointerType() function, the field values are garbage. This is exactly > at the point where execution is transitioning from clang-compiled code to > gcc-compiled code. > If I instead compile my frontend with gcc, everything works fine.There are a couple of relatively simple ways to check whether there's really a calling-convention mismatch... 1. Compile llvm+clang with clang, and link that against your clang-compiled compiler. 2. Compile everything with -m32, and see if you still see the same issue. If you can come up with a reasonable testcase, I'll take a look. -Eli
Eli Friedman
2011-Jun-28 01:32 UTC
[LLVMdev] Segfault calling LLVM libs from a clang-compiled executable
On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <eli.friedman at gmail.com> wrote:> On Fri, Jun 24, 2011 at 10:51 PM, Talin <viridia at gmail.com> wrote: >> A couple of months ago, I started the process of updating my CMake scripts >> to allow my compiler to be compiled with clang. I quickly ran into a problem >> calling the LLVM libraries, which is that I would get segfaults when calling >> LLVM API functions. I posted about this on both the clang and llvm-dev >> lists, but there was no response, so I decided to put the clang-related work >> on hold. >> Last week I decided to pick this up again. My motivation for doing so is >> that it's much easier to work with clang's error diagnostics, and coding is >> generally more productive. However, I once again observed the same problem, >> which I will now attempt to describe in some detail: >> I start with a fresh checkout of both llvm and clang. Both get compiled with >> gcc (this is on the most recent version of Ubuntu, 64-bit although I've seen >> the same problem on other OS configurations.) Then I compile my compiler >> with clang, and link it against the llvm libs. Everything works fine up to a >> point - that is, I'm able to use all of the ADT classes, derived types, and >> so on - until I get into the code generation phase, at which point things >> blow up. Specifically, I get a segfault in DIBuilder::createPointerType() >> (well, actually the segfault is several stack levels down from that.) >> Looking in gdb, it appears that there is some sort of calling convention >> mismatch - my code is calling createPointerType() with an empty StringRef(), >> but when I attempt to look at the StringRef argument from within the >> createPointerType() function, the field values are garbage. This is exactly >> at the point where execution is transitioning from clang-compiled code to >> gcc-compiled code. >> If I instead compile my frontend with gcc, everything works fine. > > There are a couple of relatively simple ways to check whether there's > really a calling-convention mismatch... > > 1. Compile llvm+clang with clang, and link that against your > clang-compiled compiler. > 2. Compile everything with -m32, and see if you still see the same issue. > > If you can come up with a reasonable testcase, I'll take a look.And... I just managed to run into this myself running a clang-compiled clang linked with a gcc-compiled LLVM on OSX. I'll take a closer look. -Eli
Apparently Analagous Threads
- [LLVMdev] Segfault calling LLVM libs from a clang-compiled executable
- [LLVMdev] Segfault calling LLVM libs from a clang-compiled executable
- [LLVMdev] Segfault calling LLVM libs from a clang-compiled executable
- [LLVMdev] Segfault calling LLVM libs from a clang-compiled executable
- [LLVMdev] Segfault calling LLVM libs from a clang-compiled executable