[webkit-dev] x86-64 JIT

[Mike Hommey]

On Wed, Mar 18, 2009 at 08:54:27AM +0100, Mike Hommey wrote:
> On Wed, Mar 18, 2009 at 08:02:06AM +0100, Mike Hommey wrote:
> > On Tue, Mar 17, 2009 at 05:09:10PM -0700, Maciej Stachowiak wrote:
> > >
> > > On Mar 17, 2009, at 1:51 PM, Mike Hommey wrote:
> > >
> > >> Hi,
> > >>
> > >> I was taking a quick look at the JIT code and also gave a shot at
> > >> forcing a build of the x86-64 code under Linux.
> > >>
> > >> The main problem right now is the following:
> > >> ../JavaScriptCore/jit/JITArithmetic.cpp:664: error: cast from  
> > >> 'JSC::Structure*' to 'unsigned int' loses precision
> > >> ../JavaScriptCore/jit/JITArithmetic.cpp:674: error: cast from  
> > >> 'JSC::Structure*' to 'unsigned int' loses precision
> > >> ../JavaScriptCore/jit/JITArithmetic.cpp:714: error: cast from  
> > >> 'JSC::Structure*' to 'unsigned int' loses precision
> > >> ../JavaScriptCore/jit/JITArithmetic.cpp:724: error: cast from  
> > >> 'JSC::Structure*' to 'unsigned int' loses precision
> > >>
> > >> Looking at the code, it seems really too much x86-centric, and
> > >> depending on how the x86-64 ABI is under OSX. I don't know how things
> > >> are going to evolve with Snow-Leopard, as I hear the kernel will  
> > >> finally
> > >> be 64-bits, but maybe the same issue will arise.
> > >
> > > The x86_64 ABI is standardized, so it should match between Linux and OS X 
> > > for the things we care about.
> > >
> > >> Anyways, I'd need guidance from some people with JIT knowledge to help
> > >> me get it work on Linux.
> > >
> > > Sounds like either ALTERNATE_JSIMMEDIATE or JIT_OPTIMIZE_ARITHMETIC is  
> > > not defined for you. It should be defined on x86_64. But it also sounds 
> > > like a bug that pointers are being cast to unsigned in this code path. 
> > > I'm not sure offhand how to fix it. But making sure those two 
> > > preprocessor symbols are set should help.
> > 
> > Oh thanks, that was it. I removed one PLATFORM(MAC) for ENABLE_JIT but
> > missed the one for ALTERNATE_JSIMMEDIATE. It built. I'll check if it
> > works (and will probably enable it in the debian packages, so that it is
> > mode widely tested)
> 
> FWIW, it crashes with a corrupted stack:
> (gdb) bt
> #0  0x00007fd115002c00 in ?? ()
> #1  0x00007fd11f4f6d26 in JSC::JITStubs::cti_op_call_NotJSFunction (args=0x7fff27e13820) at ../JavaScriptCore/runtime/JSCell.h:206
> #2  0x00007fd11fc55a3a in ?? ()
> #3  0x0000000000000000 in ?? ()
> 
> I'll investigate later today.

It appears it's not exactly a corrupted stack, yet, it's sad the JIT
code doesn't do the right thing to allow gdb to trace back to earlier
frames.

Anyways, it really does crash in JSC::JITStubs::cti_op_call_NotJSFunction.
To be more precise, it crashes on the following line:
    CallType callType = funcVal.getCallData(callData);
which is actually:
    inline CallType JSValuePtr::getCallData(CallData& callData)
    {
        return JSImmediate::isImmediate(asValue()) ? CallTypeNone : asCell()->getCallData(callData);
    }

It appears asCell() here is returning something wrong (not NULL).

An earlier call to JSC::JITStubs::cti_op_call_NotJSFunction works and a lot
of other stub functions are called before the crash, so it means most of
the JIT works, but it is failing in a subtle way.

Would someone with JIT knowledge have some hints to debug this crasher ?

Cheers,

Mike