[RFC/JVMTI] GetMethodDeclaringClass

[Keith Seitz]

Andrew Haley wrote:
> I understand.  Let's not re-introuce this bug.  We could push these
> entries into a separate map or maybe when (looking them up during a
> stacktrace) check that the result isn't an interpreted class.  Either
> would work, and neither is a huge additional overhead.

Okay, I've chosen the latter approach (check if the class is interpreted 
when doing backtraces).

How does this look? [It would be really appreciated if someone with 
access to ppc64-linux or somesuch could double-check for a failure in 
the stack tracing tests in lang.exp.]

Keith

ChangeLog
2006-10-23  Keith Seitz  <keiths@redhat.com>

         * include/java-stack.h (ncodeMap): Declare.
         (_Jv_StackTrace): Make _Jv_GetMethodDeclaringClass friend.
         * java/lang/Class.h (_Jv_GetMethodDeclaringClass): Declare.
         * java/lang/natClass.cc (_Jv_GetMethodDeclaringClass): New
         function.
         * stacktrace.cc (ncodeMap): Redefine from file global to global
         for class _Jv_StackTrace.
         (_Jv_StackTrace::UpdateNCodeMap): Add interpreted classes, too,
         so that _Jv_GetMethodDeclaringClass can find them all.
         (_Jv_StackTrace::ClassForFrame): Exclude interpreted classes.
         * jvmti.cc (_Jv_JVMTI_GetMethodDeclaringClass): New function.
         (_Jv_JVMTI_Interface): Define GetMethodDeclaringClass function.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: getmethoddeclaringclass.patch
Type: text/x-patch
Size: 5264 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20061023/b4aa0e42/attachment.bin>