[squirrelfish] cti functions and emit_op_new_array

[wingoog moon]

I've tried to debug DEFINE_STUB_FUNCTION(JSObject*, op_new_array) function,
and here  what my disassemble showed when I tried to go up and see who
called this function.

Dump of assembler code from 0x7fffb5c98349 to 0x7fffb5c98389:

   0x00007fffb5c98349: add    %al,(%rax)

   0x00007fffb5c9834b: mov    %rax,0x0(%r13)

   0x00007fffb5c9834f: movl   $0x0,0x8(%rsp)

   0x00007fffb5c98357: movl   $0x1,0x10(%rsp)

   0x00007fffb5c9835f: mov    %rsp,%rdi

   0x00007fffb5c98362: mov    %r13,0x58(%rsp)

   0x00007fffb5c98367: movl   $0x5,-0x2c(%r13)

   0x00007fffb5c9836f: movabs $0xc60d60,%r11

   0x00007fffb5c98379: mov    %r13,(%r11)

   0x00007fffb5c9837c: movabs $0x5bfda6,%r11

   0x00007fffb5c98386: callq  *%r11

This code is generated by emit_op_new_array. Everything is
understandable except "movabs $0x5bfda6,%r11".
Let's look to the Call function in MacroAssemblerx86_64.h which generates
 call instruction.

Call call()
    {
        DataLabelPtr label = moveWithPatch(TrustedImmPtr(0),
scratchRegister);
        Call result = Call(m_assembler.call(scratchRegister),
Call::Linkable);
        ASSERT_UNUSED(label, differenceBetween(label, result) ==
REPTACH_OFFSET_CALL_R11);
        return result;
    }

And here we move TrustedImmPtr(0) to scratchRegister(%r11).
So the question is how movabs $0x5bfda6,%r11 generated? Is it kind a magic
??))

Thanks!


On Sat, Mar 31, 2012 at 8:56 PM, Gavin Barraclough <barraclough at apple.com>wrote:

> On Mar 31, 2012, at 6:13 AM, wingoog moon <wingoog91 at gmail.com> wrote:
>
> > stubCall.call(currentInstruction[1].u.operand)  calls function
> DEFINE_STUB_FUNCTION(JSObject*, op_new_array) from JITStubs.cpp. And at
> this point execution of our JS programm is "interputing" and here C
> functions starting  to work to "create array".
>
> Just to be clear, this line of code does not directly call the cti helper
> stub, this is compiling JIT code, that when run will call the helper stub.
> Local variables & temporary values between operations are stored in the
> VM's register file, indexed by virtual register numbers. For the new_array
> opcode (and most opcodes) the virtual register indicating where to store
> the result in is stored in the bytecode instruction stream immediately
> after the opcode - and is being accessed here by the expression
> "currentInstruction[1].u.operand". The argument to the call method here is
> the virtual register number to store the result back to.
>
> G.
>
> Sent from my iPhone
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/squirrelfish-dev/attachments/20120403/6045fa3d/attachment.html>