[webkit-dev] Gtklauncher crashes when WML is turned ON

[mwas]

Hi

I used WebKit rev-40777 and turned ON WML support. The build goes
successfully.

Lauching GtkLauncher gives segmentation fault with the following BT

Program received signal SIGSEGV, Segmentation fault.
0x4023c9d4 in WebCore::Document::cacheDocumentElement () from
/usr/local/lib/libwebkit-1.0.so.1
Current language: auto; currently asm
(gdb) bt
#0 0x4023c9d4 in WebCore::Document::cacheDocumentElement () from
/usr/local/lib/libwebkit-1.0.so.1
#1 0x403483f0 in WebCore::HTMLParser::handleError () from
/usr/local/lib/libwebkit-1.0.so.1
#2 0x40349790 in WebCore::HTMLParser::insertNode () from
/usr/local/lib/libwebkit-1.0.so.1
#3 0x40a3dc60 in ?? () from /usr/local/lib/libwebkit-1.0.so.1

I think there is some problem while inserting nodes

Pl. suggest anything i can solve this problem.

thanks

mwas
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] how to store javascript identifier

[zhenghe zhang]

Hi all
Now I have a diffcult problem, and I don't how to solve it.
I hope you help me, thank you!
When running a webpage, and the javascriptcore will parse the
javascript function, and will obtain some identifiers.  I don't know how to
store these identifiers and where to store these identifiers.
Thank you
Regards
zh

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Gtklauncher crashes when WML is turned ON

[George Staikos]

Bug reports should be filed at bugs.webkit.org

On 3-Mar-09, at 5:02 PM, mwas wrote:


Hi

I used WebKit rev-40777 and turned ON WML support. The build goes  
successfully.


Lauching GtkLauncher gives segmentation fault with the following BT

Program received signal SIGSEGV, Segmentation fault.
0x4023c9d4 in WebCore::Document::cacheDocumentElement () from /usr/ 
local/lib/libwebkit-1.0.so.1

Current language: auto; currently asm
(gdb) bt
#0 0x4023c9d4 in WebCore::Document::cacheDocumentElement () from / 
usr/local/lib/libwebkit-1.0.so.1
#1 0x403483f0 in WebCore::HTMLParser::handleError () from /usr/ 
local/lib/libwebkit-1.0.so.1
#2 0x40349790 in WebCore::HTMLParser::insertNode () from /usr/local/ 
lib/libwebkit-1.0.so.1

#3 0x40a3dc60 in ?? () from /usr/local/lib/libwebkit-1.0.so.1

I think there is some problem while inserting nodes

Pl. suggest anything i can solve this problem.



--
George Staikos
Torch Mobile Inc.
http://www.torchmobile.com/

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined?

[x yz]

in jit.h, for example:
static const int patchOffsetOpCallCompareToJump = 9;
static const int patchOffsetPutByIdStructure = 7;
static const int patchOffsetPutByIdPropertyMapOffset = 22;
static const int patchOffsetGetByIdBranchToSlowCase = 13;
thanks for help, I'm stucked here now.
joe


--- On Sat, 2/28/09, Gavin Barraclough barraclo...@apple.com wrote:

 From: Gavin Barraclough barraclo...@apple.com
 Subject: Re: [webkit-dev] want to port JIT to MIPS - JIT reg usage clean up?
 To: WebKit Development webkit-dev@lists.webkit.org
 Date: Saturday, February 28, 2009, 12:19 PM
 On Feb 27, 2009, at 4:55 PM, x yz wrote:
 
  The regTx seems to be working registers here, yet
 their definition are regparm(3) registers for function
 arugments. Such usage would cause conflict on other
 platforms. May I suggest that we use individual defined set
 of regs for func i/o argument and working?
 
 First up, I think you're getting slightly confused
 about regparm(3).  This is not used anywhere in the JS
 language JIT, only in WREC.  In some configurations of the
 JIT we use fastcall semantics on x86... but none of this is
 really relevant to MIPS.  Just ignore all this.  Stick to
 the default MIPS ABI for stub functions.
 
 Reading between the lines, I'm guessing your concern
 here is that in setting up arguments for a JIT stub call you
 may trample the JIT's temporary registers?  If so, I
 think you need to look at the argument passing more closely.
  The mechanisms to pass arguments to stub functions pass all
 arguments in memory – typically passing a single pointer
 to the stub functions, which can be used to retrieve the
 arguments.  This pointer argument can be set up immediately
 prior to the call, so it does not interfere with the regT?
 temporaries.  We follow this pattern on x86-64, where the
 ABI is typically to pass arguments in registers.  You cannot
 trivially change the way this works, since the argument
 pointer is used for other purposes too (e.g. retrieving the
 arguments passed into the JIT code from within the stubs).
 
 We strongly prefer small, simple, incremental changes.  A
 patch that tried to both port the JIT to a new platform and
 to introduce a new argument passing interface to the JIT
 stub functions sounds unlikely to get anywhere (a patch
 porting the JIT to a new platform is on its own very likely
 to be too much more than we'd want to land in one
 chunk).  I'd suggest that a port would be wise to
 engineer it's initial solution to fit one of the
 existing argument passing mechanisms (these are selected by
 JIT_STUB_ARGUMENT_* switches, to help find the relevant
 code).  (Alternatively, you're welcome to attempt to
 port x86-64 to make use of an in-register argument passing
 solution, which could be hugely useful.  With this landed
 first and separately, a port could then build on top of
 this.)
 
 As a more direct answer to your question, you could
 endeavour to make the set of hardware registers used as JIT
 temporaries non-overlapping with ABI function argument
 registers on MIPS, but this is unlikely to be a general
 solution to anything for all platforms, due to limited
 register availability on some architectures.
 
  we would put all these definition in a file named
 regMap.h, then we can remove all X86:: from
 other JIT files.
 
 I don't think we'll be keen on taking preemptive
 changes so far ahead in preparation of a port.  The first
 logical step in porting to a new platform is still to start
 with WREC, and this requires no changes in the JIT
 directory.  Any refactoring of the existing JIT would make
 more sense more directly prior to work in that area.
 
 cheers,
 G.
 
  
  I'd apperciate if sb can do it or help me to do
 it.
  rgds
  joe
  
  
  
  
  --- On Sat, 2/28/09, x yz last...@yahoo.com
 wrote:
  
  From: x yz last...@yahoo.com
  Subject: Re: [webkit-dev] want to port JIT to MIPS
 - which calling convention is used here?
  To: webkit-dev@lists.webkit.org, Zoltan
 Herczeg zherc...@inf.u-szeged.hu
  Date: Saturday, February 28, 2009, 7:40 AM
  Hi,
  Thanks for your help in advance:)
  in JITPropertyAccess.cpp:
 if
 (transitionWillNeedStorageRealloc(oldStructure,
  newStructure)) {
 pop(X86::ebx);  ///pop return address,
 why? for
  exception?
  #if PLATFORM(X86_64)///which convention is
 this?
  
 
 move(Imm32(newStructure-propertyStorageCapacity()),
  regT1);  //edx
  
 
 move(Imm32(oldStructure-propertyStorageCapacity()),
  X86::esi);
 move(regT0, X86::edi);
 callTarget = call();
  #else   ///__cdecl, yet how
 can I know
  resizePropertyStorage() use __cdecl?
  
 
 push(Imm32(newStructure-propertyStorageCapacity()));
  
 
 push(Imm32(oldStructure-propertyStorageCapacity()));
 push(regT0);
 callTarget = call();
 addPtr(Imm32(3 * sizeof(void*)), X86::esp);
  ///clean stack
  #endif
  
  
  
  
  
  
  
  ___
  

Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined?

[Zoltan Herczeg]

On x86, the size of the instructions are fixed. If you want to access
multiple instructions in the instruction stream, you only need to store
the address of the first one, and can access the others by their relative
address. This saves a little memory.

Example (see JIT::linkCall):
  instruction at callLinkInfo-hotPathBegin: points to callee comparison
  instruction at
callLinkInfo-hotPathBegin + patchOffsetOpCallCompareToJump:
   points to the slow case entry jump

Zoltan

 in jit.h, for example:
 static const int patchOffsetOpCallCompareToJump = 9;
 static const int patchOffsetPutByIdStructure = 7;
 static const int patchOffsetPutByIdPropertyMapOffset = 22;
 static const int patchOffsetGetByIdBranchToSlowCase = 13;
 thanks for help, I'm stucked here now.
 joe


 --- On Sat, 2/28/09, Gavin Barraclough barraclo...@apple.com wrote:

 From: Gavin Barraclough barraclo...@apple.com
 Subject: Re: [webkit-dev] want to port JIT to MIPS - JIT reg usage clean
 up?
 To: WebKit Development webkit-dev@lists.webkit.org
 Date: Saturday, February 28, 2009, 12:19 PM
 On Feb 27, 2009, at 4:55 PM, x yz wrote:

  The regTx seems to be working registers here, yet
 their definition are regparm(3) registers for function
 arugments. Such usage would cause conflict on other
 platforms. May I suggest that we use individual defined set
 of regs for func i/o argument and working?

 First up, I think you're getting slightly confused
 about regparm(3).  This is not used anywhere in the JS
 language JIT, only in WREC.  In some configurations of the
 JIT we use fastcall semantics on x86... but none of this is
 really relevant to MIPS.  Just ignore all this.  Stick to
 the default MIPS ABI for stub functions.

 Reading between the lines, I'm guessing your concern
 here is that in setting up arguments for a JIT stub call you
 may trample the JIT's temporary registers?  If so, I
 think you need to look at the argument passing more closely.
  The mechanisms to pass arguments to stub functions pass all
 arguments in memory – typically passing a single pointer
 to the stub functions, which can be used to retrieve the
 arguments.  This pointer argument can be set up immediately
 prior to the call, so it does not interfere with the regT?
 temporaries.  We follow this pattern on x86-64, where the
 ABI is typically to pass arguments in registers.  You cannot
 trivially change the way this works, since the argument
 pointer is used for other purposes too (e.g. retrieving the
 arguments passed into the JIT code from within the stubs).

 We strongly prefer small, simple, incremental changes.  A
 patch that tried to both port the JIT to a new platform and
 to introduce a new argument passing interface to the JIT
 stub functions sounds unlikely to get anywhere (a patch
 porting the JIT to a new platform is on its own very likely
 to be too much more than we'd want to land in one
 chunk).  I'd suggest that a port would be wise to
 engineer it's initial solution to fit one of the
 existing argument passing mechanisms (these are selected by
 JIT_STUB_ARGUMENT_* switches, to help find the relevant
 code).  (Alternatively, you're welcome to attempt to
 port x86-64 to make use of an in-register argument passing
 solution, which could be hugely useful.  With this landed
 first and separately, a port could then build on top of
 this.)

 As a more direct answer to your question, you could
 endeavour to make the set of hardware registers used as JIT
 temporaries non-overlapping with ABI function argument
 registers on MIPS, but this is unlikely to be a general
 solution to anything for all platforms, due to limited
 register availability on some architectures.

  we would put all these definition in a file named
 regMap.h, then we can remove all X86:: from
 other JIT files.

 I don't think we'll be keen on taking preemptive
 changes so far ahead in preparation of a port.  The first
 logical step in porting to a new platform is still to start
 with WREC, and this requires no changes in the JIT
 directory.  Any refactoring of the existing JIT would make
 more sense more directly prior to work in that area.

 cheers,
 G.

 
  I'd apperciate if sb can do it or help me to do
 it.
  rgds
  joe
 
 
 
 
  --- On Sat, 2/28/09, x yz last...@yahoo.com
 wrote:
 
  From: x yz last...@yahoo.com
  Subject: Re: [webkit-dev] want to port JIT to MIPS
 - which calling convention is used here?
  To: webkit-dev@lists.webkit.org, Zoltan
 Herczeg zherc...@inf.u-szeged.hu
  Date: Saturday, February 28, 2009, 7:40 AM
  Hi,
  Thanks for your help in advance:)
  in JITPropertyAccess.cpp:
 if
 (transitionWillNeedStorageRealloc(oldStructure,
  newStructure)) {
 pop(X86::ebx);  ///pop return address,
 why? for
  exception?
  #if PLATFORM(X86_64)///which convention is
 this?
 
 
 move(Imm32(newStructure-propertyStorageCapacity()),
  regT1);  //edx
 
 
 move(Imm32(oldStructure-propertyStorageCapacity()),
  X86::esi);
 

[webkit-dev] Detecting paste with cmd-v on Mac

[Rush Manbert]

I was testing some JavaScript code that a colleague wrote that does  
special handling when a user attempts to pastes a string into a text  
input box. He had developed it using Safari.


There s a routine that processes keyDown events. In it, he gets the  
charCode value from the keyEvent like this:
var charCode = (evt.charCode) ? evt.charCode : ((evt.keyCode) ?  
evt.keyCode : ((evt.which ? evt.which : 0)));


After that, he checks for the WebKit browser, then does this:
if(charCode == 86)
return; // Don't mess around with the paste keyCode

This worked for Safari, but didn't work in my custom browser that uses  
WebKit. The difference is that in Safari, evt.charCode == 0, and  
evt.keyCode == 86, so charCode ends up with the value 86. However,  
when I use WebKit, I see evt.charCode == 118 and evt.keyCode == 86, so  
charCode ends up with the value of 118.


I checked the values of the DOM even modifiers alyKey, ctrlKey, and  
shiftKey and they are all false on a cmd-v paste


Further testing reveals that the code shown above cannot detect the  
difference between cmd-v and v, and detects shift-v as a cmd-v paste  
because evt.charCode == 86 in that case.


I tried to handle this by adding code that detects keyDown/keyUp and  
uses a state variable. I set it true when I see a keyDown event with  
evt.charCode == 91 and I set it false when I see a keyUp event with  
evt.charCode == 91. Then I check for the state variable true and  
charCode == 118 when I'm looking for a paste.


That seems to work for both WebKit and Safari.

Is there another way to handle this? Is the difference between Safari  
and WebKit expected?


- Rush

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Debugger shows empty javascript file when reloading page

[Husam Senussi]

Hi,

for some reason the debugger in the web inspector shows blank script  
when I reload the page, also

the resource tab shows the file with wrong type.

I tried it with the latest nightly build as will getting the same  
thing, I only see the script when open and close the

browser.


Thanks 
  
___

webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined?

[x yz]

Zoltan,
Thanks for reply, I'm trying to understand your example. But,X86 instruction 
size is from 1 to 17bytes, not constant. I may misunderstand your comments?
Many X86 instruction can have imm32 at the end, thus this pointer can be used 
for patch as well as next address after call. Does Arm have similar things? or 
else you still need to figure out why patchOffsetOpCallCompareToJump = 9;? 
may be some instruction lengths relates to the 9?
rgds
joe


--- On Wed, 3/4/09, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote:

 From: Zoltan Herczeg zherc...@inf.u-szeged.hu
 Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* 
 constant determined?
 To: webkit-dev@lists.webkit.org
 Date: Wednesday, March 4, 2009, 3:45 AM
 On x86, the size of the instructions are fixed. If you want
 to access
 multiple instructions in the instruction stream, you only
 need to store
 the address of the first one, and can access the others by
 their relative
 address. This saves a little memory.
 
 Example (see JIT::linkCall):
   instruction at callLinkInfo-hotPathBegin: points to
 callee comparison
   instruction at
 callLinkInfo-hotPathBegin +
 patchOffsetOpCallCompareToJump:
points to the slow case entry jump
 
 Zoltan
 
  in jit.h, for example:
  static const int
 patchOffsetOpCallCompareToJump = 9;
  static const int patchOffsetPutByIdStructure =
 7;
  static const int
 patchOffsetPutByIdPropertyMapOffset = 22;
  static const int
 patchOffsetGetByIdBranchToSlowCase = 13;
  thanks for help, I'm stucked here now.
  joe
 
 
  --- On Sat, 2/28/09, Gavin Barraclough
 barraclo...@apple.com wrote:
 
  From: Gavin Barraclough
 barraclo...@apple.com
  Subject: Re: [webkit-dev] want to port JIT to MIPS
 - JIT reg usage clean
  up?
  To: WebKit Development
 webkit-dev@lists.webkit.org
  Date: Saturday, February 28, 2009, 12:19 PM
  On Feb 27, 2009, at 4:55 PM, x yz wrote:
 
   The regTx seems to be working registers here,
 yet
  their definition are regparm(3) registers for
 function
  arugments. Such usage would cause conflict on
 other
  platforms. May I suggest that we use individual
 defined set
  of regs for func i/o argument and working?
 
  First up, I think you're getting slightly
 confused
  about regparm(3).  This is not used anywhere in
 the JS
  language JIT, only in WREC.  In some
 configurations of the
  JIT we use fastcall semantics on x86... but none
 of this is
  really relevant to MIPS.  Just ignore all this. 
 Stick to
  the default MIPS ABI for stub functions.
 
  Reading between the lines, I'm guessing your
 concern
  here is that in setting up arguments for a JIT
 stub call you
  may trample the JIT's temporary registers?  If
 so, I
  think you need to look at the argument passing
 more closely.
   The mechanisms to pass arguments to stub
 functions pass all
  arguments in memory – typically passing a single
 pointer
  to the stub functions, which can be used to
 retrieve the
  arguments.  This pointer argument can be set up
 immediately
  prior to the call, so it does not interfere with
 the regT?
  temporaries.  We follow this pattern on x86-64,
 where the
  ABI is typically to pass arguments in registers. 
 You cannot
  trivially change the way this works, since the
 argument
  pointer is used for other purposes too (e.g.
 retrieving the
  arguments passed into the JIT code from within the
 stubs).
 
  We strongly prefer small, simple, incremental
 changes.  A
  patch that tried to both port the JIT to a new
 platform and
  to introduce a new argument passing interface to
 the JIT
  stub functions sounds unlikely to get anywhere (a
 patch
  porting the JIT to a new platform is on its own
 very likely
  to be too much more than we'd want to land in
 one
  chunk).  I'd suggest that a port would be wise
 to
  engineer it's initial solution to fit one of
 the
  existing argument passing mechanisms (these are
 selected by
  JIT_STUB_ARGUMENT_* switches, to help find the
 relevant
  code).  (Alternatively, you're welcome to
 attempt to
  port x86-64 to make use of an in-register argument
 passing
  solution, which could be hugely useful.  With this
 landed
  first and separately, a port could then build on
 top of
  this.)
 
  As a more direct answer to your question, you
 could
  endeavour to make the set of hardware registers
 used as JIT
  temporaries non-overlapping with ABI function
 argument
  registers on MIPS, but this is unlikely to be a
 general
  solution to anything for all platforms, due to
 limited
  register availability on some architectures.
 
   we would put all these definition in a file
 named
  regMap.h, then we can remove all X86::
 from
  other JIT files.
 
  I don't think we'll be keen on taking
 preemptive
  changes so far ahead in preparation of a port. 
 The first
  logical step in porting to a new platform is still
 to start
  with WREC, and this requires no changes in the JIT
  directory.  Any refactoring of the existing JIT
 

[webkit-dev] how to implement the flash block for webkit on linux?

[Suk Zhong]

Hi All:

  At present, we want to implement the flash block for webkit on linux
like flash block extension for firefox.

  We find the implemention of firefox, it's based on xbl, it's very easy
to understand.Through checking after sometime we find the branches/xbl2  of
webkit svn includes the xbl2 implemention, but don't know the degree of xbl
support and its current status, and the layouttest related to xbl is so
simple. some people know using xbl in webkit can implement the flash block?

  We also know the clicktoflash to block flash for safari on Mac,but we
need it on linux, because i can't understand xcode etc, some people can tell
me the main idea of its implemention?

 We'll appreciate for any other informations about implemention of flash
block for webkit.

Thanks and Best Regards.

Suk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined?

[Zoltan Herczeg]

Hi,

they generate instructions, which size is known in advance.

Think about the following sequence:
hotPathBegin:
  mov regX, 32bit_const - 6 bytes (*) (**)
  add regX, regY - 2 bytes
  jo 32bit_addr - 5 bytes (*)

* (Note) : these instructions will be modified during runtime.

** (Note) : there is a short form for mov regX, 8bit_const, which length
is only 3 bytes, but they force the longer version in such cases to keep
the size of the instruction.

As you can see, the address of jo is always (hotPathBegin + 6 + 2). They
simply introduce a new constant: patchOffsetXXX = 8, and use this constant
to access the jo instruction later.

In ARM we can't rely on such constant, because the constant pool can be
placed after any instruction.

hotPathBegin:
  ldr rX, [pc + const_pool_addr] ; 32 bit const
  [...] - the const pool can be placed here
  add rX, rX, rY
  [...] - the const pool can be placed here
hotPath2:
  ldr pc, [pc + const_pool_addr] ; 32 bit target address

We need to store both pointers (hotPathBegin and hotPath2).

Zoltan

 Zoltan,
 Thanks for reply, I'm trying to understand your example. But,X86
 instruction size is from 1 to 17bytes, not constant. I may misunderstand
 your comments?
 Many X86 instruction can have imm32 at the end, thus this pointer can be
 used for patch as well as next address after call. Does Arm have similar
 things? or else you still need to figure out why
 patchOffsetOpCallCompareToJump = 9;? may be some instruction lengths
 relates to the 9?
 rgds
 joe


 --- On Wed, 3/4/09, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote:

 From: Zoltan Herczeg zherc...@inf.u-szeged.hu
 Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset*
 constant determined?
 To: webkit-dev@lists.webkit.org
 Date: Wednesday, March 4, 2009, 3:45 AM
 On x86, the size of the instructions are fixed. If you want
 to access
 multiple instructions in the instruction stream, you only
 need to store
 the address of the first one, and can access the others by
 their relative
 address. This saves a little memory.

 Example (see JIT::linkCall):
   instruction at callLinkInfo-hotPathBegin: points to
 callee comparison
   instruction at
 callLinkInfo-hotPathBegin +
 patchOffsetOpCallCompareToJump:
points to the slow case entry jump

 Zoltan

  in jit.h, for example:
  static const int
 patchOffsetOpCallCompareToJump = 9;
  static const int patchOffsetPutByIdStructure =
 7;
  static const int
 patchOffsetPutByIdPropertyMapOffset = 22;
  static const int
 patchOffsetGetByIdBranchToSlowCase = 13;
  thanks for help, I'm stucked here now.
  joe
 
 
  --- On Sat, 2/28/09, Gavin Barraclough
 barraclo...@apple.com wrote:
 
  From: Gavin Barraclough
 barraclo...@apple.com
  Subject: Re: [webkit-dev] want to port JIT to MIPS
 - JIT reg usage clean
  up?
  To: WebKit Development
 webkit-dev@lists.webkit.org
  Date: Saturday, February 28, 2009, 12:19 PM
  On Feb 27, 2009, at 4:55 PM, x yz wrote:
 
   The regTx seems to be working registers here,
 yet
  their definition are regparm(3) registers for
 function
  arugments. Such usage would cause conflict on
 other
  platforms. May I suggest that we use individual
 defined set
  of regs for func i/o argument and working?
 
  First up, I think you're getting slightly
 confused
  about regparm(3).  This is not used anywhere in
 the JS
  language JIT, only in WREC.  In some
 configurations of the
  JIT we use fastcall semantics on x86... but none
 of this is
  really relevant to MIPS.  Just ignore all this.
 Stick to
  the default MIPS ABI for stub functions.
 
  Reading between the lines, I'm guessing your
 concern
  here is that in setting up arguments for a JIT
 stub call you
  may trample the JIT's temporary registers?  If
 so, I
  think you need to look at the argument passing
 more closely.
   The mechanisms to pass arguments to stub
 functions pass all
  arguments in memory – typically passing a single
 pointer
  to the stub functions, which can be used to
 retrieve the
  arguments.  This pointer argument can be set up
 immediately
  prior to the call, so it does not interfere with
 the regT?
  temporaries.  We follow this pattern on x86-64,
 where the
  ABI is typically to pass arguments in registers.
 You cannot
  trivially change the way this works, since the
 argument
  pointer is used for other purposes too (e.g.
 retrieving the
  arguments passed into the JIT code from within the
 stubs).
 
  We strongly prefer small, simple, incremental
 changes.  A
  patch that tried to both port the JIT to a new
 platform and
  to introduce a new argument passing interface to
 the JIT
  stub functions sounds unlikely to get anywhere (a
 patch
  porting the JIT to a new platform is on its own
 very likely
  to be too much more than we'd want to land in
 one
  chunk).  I'd suggest that a port would be wise
 to
  engineer it's initial solution to fit one of
 the
  existing argument passing mechanisms (these are
 selected by