From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27645 invoked by alias); 8 Feb 2014 07:08:41 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 27635 invoked by uid 89); 8 Feb 2014 07:08:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_00,GARBLED_BODY autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Feb 2014 07:08:39 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1WC21j-0000Og-BC from Yao_Qi@mentor.com ; Fri, 07 Feb 2014 23:08:35 -0800 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Feb 2014 23:08:35 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.2.247.3; Fri, 7 Feb 2014 23:07:54 -0800 Message-ID: <52F5D773.5050203@codesourcery.com> Date: Sat, 08 Feb 2014 07:08:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sasha Smundak CC: Subject: Re: [RFC][PATCH] Allow JIT unwinder provide symbol information References: <20131226183618.D264CA18A0@sasha2.mtv.corp.google.com> In-Reply-To: <20131226183618.D264CA18A0@sasha2.mtv.corp.google.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00241.txt.bz2 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 () > > 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 (齐尧)