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

[Yao Qi <yao at codesourcery dot com>]

On 12/27/2013 02:36 AM, 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.

IWBN to show how GDB behaves without this patch.

> 
> 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

I agree that JIT API can be extended to get correct symbol information.

> 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.

That is a separate problem, IMO.  GDB JIT interface was designed to deal
with JIT'ed code.  In interpreted mode, it is reasonable to me
that GDB shows the interpreter code in backtrace, because JVM is just a
typical executable, which is being debugged via GDB.  I don't know how
does your patch help to this problem.

> 
> 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.

IMHO, it is not a good idea to add "symbol provider" to the unwinder, as
it is unrelated to unwinding.  Unwinder's job is to compute the 'next'
frame_info, given one frame_info.  Displaying the function name and
source file of a frame_info is out the scope of its responsibilities.

It is fine to register "symbol provider" to interpret frames of JIT'ed
code to function name, source file, and so forth, but I feel
uncomfortable to add "symbol provider" to the unwinder, at least to
'struct frame_unwind'.

-- 
Yao (éå)