[rvm-core] Walking the stack on x86 64

[Ian Rogers]

Hi,

I have a partially working JNI compiler x86 64 and the next problem I
have encountered is that x86 64 doesn't use ebp/rbp to track the frame
base pointer - it's now optional and frees the register for general
non-volatile use. We can compile library code with an option that means
it maintains the pointer or we can work out another kludge to skip
native stack frames appearing on our stacks. Do people have a preferred
solution?

Regards,
Ian

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[David P Grove]

Ian Rogers <rogers.email@...> wrote on 10/21/2008 12:01:43 PM:
>
> I have a partially working JNI compiler x86 64 and the next problem I
> have encountered is that x86 64 doesn't use ebp/rbp to track the frame
> base pointer - it's now optional and frees the register for general
> non-volatile use. We can compile library code with an option that means
> it maintains the pointer or we can work out another kludge to skip
> native stack frames appearing on our stacks. Do people have a preferred
> solution?

I thought there was already something:  we're maintaining a word in the Processor which is the FP of the previous Java->native transition frame (which in turn saves the previous backpointer link, etc).  I don't think we trust the value in EBP or rely on being able to chain through the native frames.

--dave

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers]

David P Grove wrote:

>
> Ian Rogers <rogers.email@...> wrote on 10/21/2008 12:01:43 PM:
> >
> > I have a partially working JNI compiler x86 64 and the next problem I
> > have encountered is that x86 64 doesn't use ebp/rbp to track the frame
> > base pointer - it's now optional and frees the register for general
> > non-volatile use. We can compile library code with an option that means
> > it maintains the pointer or we can work out another kludge to skip
> > native stack frames appearing on our stacks. Do people have a preferred
> > solution?
>
> I thought there was already something:  we're maintaining a word in
> the Processor which is the FP of the previous Java->native transition
> frame (which in turn saves the previous backpointer link, etc).  I
> don't think we trust the value in EBP or rely on being able to chain
> through the native frames.
>
> --dave
>

I think holding the back link in the JNI environment is probably the
only way to go with this. The back link pointer we currently have is
purely for the task of dealing with a thread that won't run into a GC
barrier (it's in some native code that never returns). We need the base
pointer as we can't inspect this thread's registers. We still walk
through the native frames, this base pointer gives us a starting address.

Regards,
Ian

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[David P Grove]

Ian Rogers <rogers.email@...> wrote on 10/21/2008 06:05:16 PM:

> [image removed]
>
> Re: [rvm-core] Walking the stack on x86 64
>
> Ian Rogers
>
> to:
>
> Discussion of day-to-day development and design among JikesRVM core
> team members
>
> 10/21/2008 06:07 PM
>
> Please respond to Discussion of day-to-day development and design
> among JikesRVM core team members
>
> David P Grove wrote:
> >
> > Ian Rogers <rogers.email@...> wrote on 10/21/2008 12:01:43 PM:
> > >
> > > I have a partially working JNI compiler x86 64 and the next problem I
> > > have encountered is that x86 64 doesn't use ebp/rbp to track the frame
> > > base pointer - it's now optional and frees the register for general
> > > non-volatile use. We can compile library code with an option that means
> > > it maintains the pointer or we can work out another kludge to skip
> > > native stack frames appearing on our stacks. Do people have a preferred
> > > solution?
> >
> > I thought there was already something:  we're maintaining a word in
> > the Processor which is the FP of the previous Java->native transition
> > frame (which in turn saves the previous backpointer link, etc).  I
> > don't think we trust the value in EBP or rely on being able to chain
> > through the native frames.
> >
> > --dave
> >
> I think holding the back link in the JNI environment is probably the
> only way to go with this. The back link pointer we currently have is
> purely for the task of dealing with a thread that won't run into a GC
> barrier (it's in some native code that never returns). We need the base
> pointer as we can't inspect this thread's registers. We still walk
> through the native frames, this base pointer gives us a starting address.
>
> Regards,
> Ian

You're right.  I thought the code in RuntimeEntrypoints.unwindNativeStackFrame was using these backlinks
to skip over the native frames, but it isn't.  It seems to me that in principle it could though with some slight massaging.

--dave

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core