[LLVMdev] Segfault calling LLVM libs from a clang-compiled executable

[Eli Friedman]

On Mon, Jun 27, 2011 at 6:32 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> 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.

Should be fixed with r134059.

-Eli