From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32323 invoked by alias); 24 Apr 2014 13:22: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 32312 invoked by uid 89); 24 Apr 2014 13:22:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 Apr 2014 13:22:39 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3ODMb6Q016364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 Apr 2014 09:22:37 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3ODMaFu008265; Thu, 24 Apr 2014 09:22:36 -0400 Message-ID: <5359101B.1080603@redhat.com> Date: Thu, 24 Apr 2014 13:22:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sasha Smundak CC: gdb-patches@sourceware.org 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=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg00497.txt.bz2 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 () > > 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