[vmkit-commits] Breakage on trunk?

[Nicolas Geoffray]

Fixed! http://llvm.org/viewvc/llvm-project?rev=144534&view=rev

On Mon, Nov 14, 2011 at 9:15 AM, Nicolas Geoffray <
nicolas.geoffray at gmail.com> wrote:

> I think I know what's going on. Thanks for the bug report and sorry for
> the breakage Will. I'm working on a fix for today.
>
>
> On Mon, Nov 14, 2011 at 1:12 AM, Will Dietz <wdietz2 at illinois.edu> wrote:
>
>> Hi,
>>
>> I'm not sure what change introduced this, but as of r144456 I cannot
>> do a from-clean build on any of {32,64}x{classpath,openjdk}.  All
>> failures happen while building mmtk.
>>
>> I'm building against LLVM r144492 for what it's worth.
>>
>> The 32bit variants fail in the very first call to j3ResolveStaticStub
>> (which is the 1st or 2nd java instruction executed in both runtime
>> ports), with the following assertion failure:
>>
>> vmjc: /home/will/vmkit-svn/lib/J3/VMCore/JavaRuntimeJIT.cpp:436: void
>> *j3ResolveStaticStub(): Assertion `FI->Metadata != __null && "Wrong
>> stack trace"' failed.
>>
>> The 64bit variants fail later in the mmtk build process, with the
>> following:
>>
>> Thread 0x110000000 received a SIGSEGV: either the VM code or an external
>> native method is bogus. Aborting...
>>
>> I believe this failure point is the same in both--its when the first
>> NullPointerException is thrown.
>>
>> Interestingly, the 64bit builds *do* work when changing
>> "SupportsHardwareNullCheck" to 'false' in System.h.  Once MMTk is
>> built, re-enabling the hardware null checks seems to work great
>> (dacapo, etc).
>>
>> (As an aside, the hardware null checks result in significantly faster
>> execution times! ~22s instead of 33s on dacapo's antlr, for example!).
>>
>> Anyway, does anyone else see these failures or have any ideas towards
>> their cause?
>>
>> Thanks!
>>
>> ~Will
>>
>> _______________________________________________
>> vmkit-commits mailing list
>> vmkit-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/vmkit-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/vmkit-commits/attachments/20111114/351b4acc/attachment.html>