Thank you for your answer. Digging through my code I found what was
wrong.
I will send the first patch next week with the beginning of the port.
I have to clean the code a little first.

Alexandre

On Oct 22, 3:39 am, Erik Corry <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to