Cool, I'll check it out - thanks!<br><br><div class="gmail_quote">On Wed, Jun 29, 2011 at 12:07 AM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">On Mon, Jun 27, 2011 at 6:32 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:<br>


> On Sat, Jun 25, 2011 at 1:34 AM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:<br>
>> On Fri, Jun 24, 2011 at 10:51 PM, Talin <<a href="mailto:viridia@gmail.com">viridia@gmail.com</a>> wrote:<br>
>>> A couple of months ago, I started the process of updating my CMake scripts<br>
>>> to allow my compiler to be compiled with clang. I quickly ran into a problem<br>
>>> calling the LLVM libraries, which is that I would get segfaults when calling<br>
>>> LLVM API functions. I posted about this on both the clang and llvm-dev<br>
>>> lists, but there was no response, so I decided to put the clang-related work<br>
>>> on hold.<br>
>>> Last week I decided to pick this up again. My motivation for doing so is<br>
>>> that it's much easier to work with clang's error diagnostics, and coding is<br>
>>> generally more productive. However, I once again observed the same problem,<br>
>>> which I will now attempt to describe in some detail:<br>
>>> I start with a fresh checkout of both llvm and clang. Both get compiled with<br>
>>> gcc (this is on the most recent version of Ubuntu, 64-bit although I've seen<br>
>>> the same problem on other OS configurations.) Then I compile my compiler<br>
>>> with clang, and link it against the llvm libs. Everything works fine up to a<br>
>>> point - that is, I'm able to use all of the ADT classes, derived types, and<br>
>>> so on - until I get into the code generation phase, at which point things<br>
>>> blow up. Specifically, I get a segfault in DIBuilder::createPointerType()<br>
>>> (well, actually the segfault is several stack levels down from that.)<br>
>>> Looking in gdb, it appears that there is some sort of calling convention<br>
>>> mismatch - my code is calling createPointerType() with an empty StringRef(),<br>
>>> but when I attempt to look at the StringRef argument from within the<br>
>>> createPointerType() function, the field values are garbage. This is exactly<br>
>>> at the point where execution is transitioning from clang-compiled code to<br>
>>> gcc-compiled code.<br>
>>> If I instead compile my frontend with gcc, everything works fine.<br>
>><br>
>> There are a couple of relatively simple ways to check whether there's<br>
>> really a calling-convention mismatch...<br>
>><br>
>> 1. Compile llvm+clang with clang, and link that against your<br>
>> clang-compiled compiler.<br>
>> 2. Compile everything with -m32, and see if you still see the same issue.<br>
>><br>
>> If you can come up with a reasonable testcase, I'll take a look.<br>
><br>
> And... I just managed to run into this myself running a clang-compiled<br>
> clang linked with a gcc-compiled LLVM on OSX.  I'll take a closer<br>
> look.<br>
<br>
</div></div>Should be fixed with r134059.<br>
<font color="#888888"><br>
-Eli<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>