http://codereview.chromium.org/6170001/diff/60001/src/arm/frames-arm.h File src/arm/frames-arm.h (right):
http://codereview.chromium.org/6170001/diff/60001/src/arm/frames-arm.h#newcode112 src/arm/frames-arm.h:112: static const int kSPOffset = -1 * kPointerSize; It's look strange for me that kSPOffset == kCodeOffset. We have the following code: EnterExitFrame: mov(ip, Operand(CodeObject())); push(ip); // Accessed from ExitFrame::code_slot. // Save the frame pointer and the context in top. mov(ip, Operand(ExternalReference(Top::k_c_entry_fp_address))); str(fp, MemOperand(ip)); mov(ip, Operand(ExternalReference(Top::k_context_address))); str(cp, MemOperand(ip)); if (save_doubles) { mov(ip, Operand(0)); // Marker and alignment word. push(ip); ... } CEntryStub::GenerateCore: masm->add(lr, pc, Operand(4)); // Compute return address: (pc + 8) + 4 masm->push(lr); masm->Jump(r5); As I see SPOffset shares its place with marker but not with the Code object. In ia-32 they are different: static const int kCodeOffset = -2 * kPointerSize; static const int kSPOffset = -1 * kPointerSize; If the return address is never fixed from GC (since the the CEntryStub is de facto unmovable) it may explain why it doesn't crash. http://codereview.chromium.org/6170001/diff/60001/src/arm/macro-assembler-arm.cc File src/arm/macro-assembler-arm.cc (right): http://codereview.chromium.org/6170001/diff/60001/src/arm/macro-assembler-arm.cc#newcode1464 src/arm/macro-assembler-arm.cc:1464: int frame_alignment = ActivationFrameAlignment(); On 2011/01/20 13:23:51, zaheer wrote:
On 2011/01/20 12:09:28, SeRya wrote: > Currently CEntryStub stack layout is following: > <caller stack frame> > <stack alignment place holder initialized by 0?> > <caller frame pointer> > <caller stack pointer after unwinding> > <return address> > <code object> > <return address to the stub or 0-marker> > <fp state?> > > Your layout: > <caller stack frame> > <caller frame pointer> > <caller stack pointer after unwinding> > <1-marker> > <pointer to the return address> > <stack alignment uninitialized place holder?> > <return address> > <code object> > <return address> Explaining the issue below, my layout in bit more detail <caller stack frame> <return address> <caller stack pointer after unwinding> <caller frame pointer> <code object> <-- centry sp, cant use the same in current case <marker> <exit frame sp> . . <arguments> . . <stack alignment>
the placeholder above arguments.
<return address> <native call stack>
I cannot completely reuse the exit frame layout since arguments come
in between
exit frame and the native entry and hence the need to put additional
slot
(marker/stack) to point to return address.
If you already considered the above issue, maybe i miss your point.
Sorry, I forget about the arguments. But it's possible anyway to come to the compatible layout. In contrast with ia32/x64 return address don't forced to be on top of the stack. Lets put in in a fixed place instead of stack top: 1. Reserve room for the return address where it's expected to be in CEntryStub (just before arguments): sub(sp, sp, Operand((arg_stack_space + 1) * kPointerSize)); (for now there is the marker at this place, so it is not needed) 2. Don't push the return address, put it to that place: add(ip, pc, Operand(4)); str(ip, MemOperand(fp, ExitFrameConstants::kSPOffset)); Jump(r2); // Call the api function. 3. In DirectCEntryStub::Generate use this slot to get real return address: ldr(ip, MemOperand(fp, ExitFrameConstants::kSPOffset)); http://codereview.chromium.org/6170001/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
