llvm dev - Jul 2011 - [LLVMdev] Segfault calling LLVM libs from a clang-compiled executable

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>

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>

On Sat, Jul 23, 2011 at 5:09 PM, Talin <viridia at gmail.com>
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