[LLVMdev] Segfault calling LLVM libs from a clang-compiled executable
Talin
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>
>> 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
>>
>
>
>
> --
> -- Talin
>
--
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110723/eee0f5aa/attachment.html>
More information about the llvm-dev
mailing list