Re: [RFC][PATCH] Allow JIT unwinder provide symbol information

[Pedro Alves <palves@redhat.com>]

On 12/26/2013 06:36 PM, Sasha Smundak wrote:
> The change proposed in this RFC is part of the effort to support
> debugging applications containing Java code executed with the help of
> Java interpreter/ just-in-time (JIT) compiler. Here's the fragment of
> the backtrace of an application being debugged by the GDB modified to
> provide such support:
> 
> #8 0x00007fffea743b03 in JNIEnv_::CallVoidMethod (this=0x7ffff001f220, obj=0x7ffff665d810, methodID=0x7ffff019d6d0) at <...>/jdk/include/jni.h:1054
> #9 0x00007fffea7439c2 in Java_Util_callObjectMethod (env=0x7ffff001f220, myclass=0x7ffff665d840, target_object=0x7ffff665d810, method_name=0x7ffff665d818) at <...>/testjni.cc:48
> #10 0x00007fffed05ef7b in Util.callObjectMethod+0x15b[C] (java.lang.Object=???) at Util.java:-1
> #11 0x00007fffed061188 in Myclass.method1+0x68[C] (this=@f665d2a8) at Myclass.java:18
> #12 0x00007fffed005f98 in Myclass.main#I ([]=[...]) at Myclass.java:48
> #13 0x00007fffed000438 in <StubRoutines> ()
> 
> I.e., Myclass.main() calls Myclass.method1() calls
> Util.callObjectMethod(), which is implemented as a C function
> Java_Util_callObjectMethod(). Myclass.main() is interpreted, while
> Myclass.method1() is JIT-compiled.
> 
> The implementation uses GDB's JIT API, and this RFC is the GDB patch
> needed for that. The implementation of the actual debugging support
> for Java (that is, the code that unwinds Java frames and is able to
> provide symbol information for them) is not presented here; hopefully
> it will make it into OpenJDK at some point, or will be distributed
> standalone.
> 
> GDB's current JIT API is sufficient to unwind the stack frames created
> by the Java Virtual Machine (JVM). However, it needs to be extended in
> order to be able to display correct symbol information, for two
> reasons. First, there is no need to add and remove symbol information
> as JIT compiles the code and disposes of it if JIT handler can provide
> this information on demand. Second, when JVM runs Java code in the
> interpreted mode, the code address in the frame points to the
> interpreter code, which is not what should be displayed.
> 
> The solution proposed here is to add a "symbol provider" function to
> the unwinder interface and modify the code displaying frames to get
> the symbol information associated with the frame (function name,
> source location, arguments) from the frame's unwinder if it has
> symbol provider and use the current logic as a fallback strategy.
> 
> There are additional changes in this RFC exposing more GDB
> functions to the JIT handler.

Apologies for only now taking a look at what this is used for.

AFAICS, this only allows providing these.

+  JIT_FRAME_SYMBOL_ATTR_FUNCTION_NAME,
+  JIT_FRAME_SYMBOL_ATTR_LANGUAGE,
+  JIT_FRAME_SYMBOL_ATTR_SOURCE_FILE,
+  JIT_FRAME_SYMBOL_ATTR_SOURCE_LINE,
+  JIT_FRAME_SYMBOL_ATTR_FUNCTION_ARGS,

It seems to me that what you want to do here is what Python
frame filters were invented for.  IOW, I think you should
be able to write a frame filter that interacts with the Java
JIT to expose the same info to the user your API extension
is proposing.  But I think that direction would be more
flexible, even.  You could for example, hide functions
if you want (say, the JIT innards), and probably give more
detail of the args (this solution seems to provide their names
as strings only).

-- 
Pedro Alves