2009/10/22 A.Rames <[email protected]>:
>
> Hi,
>
> I have been working on the MIPS port of v8, and I have a little
> question.
It's great that you are working on the port. Please send us patches a
little at a time, rather than leaving it until a big chunk is done.
If your approach is somehow incompatible with the way we do things in
V8 then you can waste a lot of time writing things that can't get into
the V8 trunk.
>
> I am working with the JavaScript shell, and follow the ARM port code.
> My shell can compile any arithmetic operation an return with success.
> I am working on calls to JS functions. For now I just compile a script
> with a dummy function returning one of its arguments:
> myfunc(p1, p2) { return p2; }
> myfunc(2,5);
>
> I have an issue with v8 not jumping to the right place in the
> CodeGenerator::VisitCall(Call* node) function.
> The VisitCall code layout is as follow:
>
> Handle<Code> stub = ComputeCallInitialize(arg_count, in_loop);
> [...]
> frame_->CallCodeObject(stub, RelocInfo::CODE_TARGET_CONTEXT, arg_count
> + 1);
> [...]
>
> I generate and copy correctly some code through the
> ComputeCallInitialize call:
> At the stub location_ property address I can find a Code object, with
> my actual code beginning at a (Code::kHeaderSize - kHeapObjectTag)
> offset.
>
> Through CallCodeObject I end up on a call to MacroAssembler::Call
> (Handle<Code> code, RelocInfo::Mode rmod,[...]).
>
> void MacroAssembler::Call(Handle<Code> code, RelocInfo::Mode rmode,
> Condition cond, Register r1, const Operand&
> r2) {
> ASSERT(RelocInfo::IsCodeTarget(rmode));
> Call(reinterpret_cast<intptr_t>(code.location(), rmode, cond, r1,
> r2);
> }
>
> This does not work for me and I can't understand how it does on ARM.
> The code is at *(code.location()) + code_offset; and here it seems to
> me we will end up jumping to code.location() instead.
I think what is happening here is that we write the location() from
the handle into the instruction.
Later the code object is created and this can cause a garbage
collection, which can move the code object we are trying to jump to.
After the code object is created the reloc info is used to fix the
call destination to point to the right place. This is done while
copying the instructions into the new code object in the line
code->CopyFrom(desc) in heap.cc.
Because we are reading the right place out of the location of the
handle we will get the new location if the code object had moved.
The way you have done it will not work if you are unlucky enough to
get a compacting garbage collection when you create the code object.
> When I look at the ARM MacroAssembler::Call(intptr_t target,
> RelocInfo::Mode rmode, [...]) I see
> mov ra, pc
> mov pc, target => mov pc, code.location()
>
> Maybe the solution lies in the commentary saying "Emit a ldr<cond> pc,
> [pc + offset of target in constant pool].", but I can't undersand
> where we do with a constant pool offset.
> I think the intptr_t type target also indicates that target is a
> pointer to the actual address, but I still can't see when we get the
> actual code address to jump to.
>
> Debugging gives me the following:
> stub.location_ = 0x6e34e8
> *stub = 0x2ce79a21 and the generated code is thus at 0x2ce79a40 (I
> can read it in memory)
>
> With the ARM version of the code it seems I jump to 0x6e34e8 and I
> meet an illegal instruction.
> By patching the code to go to *(code.location()) + code_offset I reach
> the generated code (generated by CallIC::Generate through the
> ComputeCallInitialize call).
>
>
> Thanks for your help.
>
> Alexandre
> >
>
--~--~---------~--~----~------------~-------~--~----~
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
-~----------~----~----~----~------~----~------~--~---
