On 03/22/2017 04:07 AM, Yuan Pinghai wrote:
In my current design, the cookie is stored in a new field (named
retCookie_) of JitCode, and each JITCODE (representing an instance of
JitCode) has its own cookie. In this way, when i need the original
return-address, i can recover it by first getting the JITCODE and then
fetching the cookie. Now, my problem is how can i get the correct JITCODE
with an address (e.g. the interrupted address before bailing-out)?
The CalleeToken of JitFrameLayout frames holds either a JSFunction or a
JSScript which contains a pointer to the Baseline and Ion structure
containing references to the JitCode.
When a JitCode is invalidated (Ion), the JitCode pointer is written above
the return address. JitFrameIterator::ionScript() should do the proper work
to get the information you are looking for.
Note that JitCode are used for all trampoline code which are created when
the JitRuntime is created. (see Trampoline-*.cpp files) and these should be
registered on the Runtime.
Our stack frames are making assumption about the alignment of the stack,
thus if you add any fields in the CommonFrameLayout, or JitFrameLayout,
these might cause issue in all code able to produce code, in which case you
should look for MacroAssembler::call and MacroAssembler::callJit.
WebAssembly / Asm.js are not using any of the Jit frames. Instead they are
using the same frame layout as the ABI of the system, with some variations
around the manipulation of SIMD registers.
Could some body give me a tip? Any suggestions are welcome. I appreciate
for the help!
To be honest, our stack frames are not the easiest thing to manipulate.
Maybe to prototype it, it would be easier to create some reserved memory
which is used as a second stack space which only contains the cookies?
You could store them as part of the JSContext*, and fetch the one
corresponding to the top of the stack.
By the way, i am working on Spidermonkey 45. By honest, i don't think i
have enough knowledge on fixing the bailing-out and exception handling
mechanisms, i also need suggestions on them.
What are you issues with bailouts and exceptions? They are basically
reading a register dump from the stack to build a MachineState (structure of
pointers to each register spilled location if any) and then unwind the frame
and in case of a bailout replace it by the one created by Baseline.
What would matter would be to edit the return address, knowing the caller &
callee, which you should have in both cases with the JitFrameIterator.
--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
