[LLVMdev] Segfault calling LLVM libs from a clang-compiled executable
viridia at gmail.com
Sat Jul 23 17:09:06 PDT 2011
So this was working fine for me until a few days ago when I checked out the
most recent LLVM - the one with the new type system. Now I am getting the
same error that I was getting previously.
Is it possible that your fix got unfixed when they merged in the new branch?
On Thu, Jun 30, 2011 at 2:21 PM, Talin <viridia at gmail.com> wrote:
> Cool, I'll check it out - thanks!
> On Wed, Jun 29, 2011 at 12:07 AM, Eli Friedman <eli.friedman at gmail.com>wrote:
>> On Mon, Jun 27, 2011 at 6:32 PM, Eli Friedman <eli.friedman at gmail.com>
>> > On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <eli.friedman at gmail.com>
>> >> 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
>> >>> to allow my compiler to be compiled with clang. I quickly ran into a
>> >>> calling the LLVM libraries, which is that I would get segfaults when
>> >>> 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
>> >>> 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
>> >>> 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
>> >>> 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
>> >>> blow up. Specifically, I get a segfault in
>> >>> (well, actually the segfault is several stack levels down from that.)
>> >>> Looking in gdb, it appears that there is some sort of calling
>> >>> mismatch - my code is calling createPointerType() with an empty
>> >>> but when I attempt to look at the StringRef argument from within the
>> >>> createPointerType() function, the field values are garbage. This is
>> >>> at the point where execution is transitioning from clang-compiled code
>> >>> 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
>> >> 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.
> -- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev