Segfault calling LLVM libs from a clang-compiled executable

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Segfault calling LLVM libs from a clang-compiled executable

Talin-3
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:


--
-- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault calling LLVM libs from a clang-compiled executable

Eli Friedman-2
On Fri, Jun 24, 2011 at 10:51 PM, Talin <[hidden email]> 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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault calling LLVM libs from a clang-compiled executable

Eli Friedman-2
On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <[hidden email]> wrote:

> On Fri, Jun 24, 2011 at 10:51 PM, Talin <[hidden email]> 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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault calling LLVM libs from a clang-compiled executable

Eli Friedman-2
On Mon, Jun 27, 2011 at 6:32 PM, Eli Friedman <[hidden email]> wrote:

> On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <[hidden email]> wrote:
>> On Fri, Jun 24, 2011 at 10:51 PM, Talin <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault calling LLVM libs from a clang-compiled executable

Talin-3
Cool, I'll check it out - thanks!

On Wed, Jun 29, 2011 at 12:07 AM, Eli Friedman <[hidden email]> wrote:
On Mon, Jun 27, 2011 at 6:32 PM, Eli Friedman <[hidden email]> wrote:
> On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <[hidden email]> wrote:
>> On Fri, Jun 24, 2011 at 10:51 PM, Talin <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault calling LLVM libs from a clang-compiled executable

Talin-3
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 <[hidden email]> wrote:
Cool, I'll check it out - thanks!


On Wed, Jun 29, 2011 at 12:07 AM, Eli Friedman <[hidden email]> wrote:
On Mon, Jun 27, 2011 at 6:32 PM, Eli Friedman <[hidden email]> wrote:
> On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <[hidden email]> wrote:
>> On Fri, Jun 24, 2011 at 10:51 PM, Talin <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault calling LLVM libs from a clang-compiled executable

Eli Friedman-2
On Sat, Jul 23, 2011 at 5:09 PM, Talin <[hidden email]> wrote:
> 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?

I wouldn't be surprised if something broke, but I would be surprised
if it's exactly the same issue.  It's crashing calling
DIBuilder::createPointerType again?

-Eli
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault calling LLVM libs from a clang-compiled executable

Eli Friedman-2
On Sat, Jul 23, 2011 at 6:32 PM, Eli Friedman <[hidden email]> wrote:
> On Sat, Jul 23, 2011 at 5:09 PM, Talin <[hidden email]> wrote:
>> 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?
>
> I wouldn't be surprised if something broke, but I would be surprised
> if it's exactly the same issue.  It's crashing calling
> DIBuilder::createPointerType again?

Did you ever make any progress narrowing this down?

-Eli

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault calling LLVM libs from a clang-compiled executable

Talin-3
On Wed, Aug 17, 2011 at 5:46 PM, Eli Friedman <[hidden email]> wrote:
On Sat, Jul 23, 2011 at 6:32 PM, Eli Friedman <[hidden email]> wrote:
> On Sat, Jul 23, 2011 at 5:09 PM, Talin <[hidden email]> wrote:
>> 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?
>
> I wouldn't be surprised if something broke, but I would be surprised
> if it's exactly the same issue.  It's crashing calling
> DIBuilder::createPointerType again?

Did you ever make any progress narrowing this down?

Sorry, it's still on my to-do list. 

-Eli



--
-- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Segfault calling LLVM libs from a clang-compiled executable

Talin-3
In reply to this post by Eli Friedman-2
I figured it out. Apparently an old version of clang got installed in /usr/bin, so my cmake script picked up that version instead of the new one from svn. So false alarm basically.

On Wed, Aug 17, 2011 at 5:46 PM, Eli Friedman <[hidden email]> wrote:
On Sat, Jul 23, 2011 at 6:32 PM, Eli Friedman <[hidden email]> wrote:
> On Sat, Jul 23, 2011 at 5:09 PM, Talin <[hidden email]> wrote:
>> 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?
>
> I wouldn't be surprised if something broke, but I would be surprised
> if it's exactly the same issue.  It's crashing calling
> DIBuilder::createPointerType again?

Did you ever make any progress narrowing this down?

-Eli



--
-- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev