[LLVMdev] Segfault calling LLVM libs from a clang-compiled executable

[Talin]

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>