llvm dev - Jun 2011 - [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

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110630/9b024b6d/attachment.html>