From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15214 invoked by alias); 13 Feb 2012 09:11:58 -0000 Received: (qmail 15205 invoked by uid 22791); 13 Feb 2012 09:11:57 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Feb 2012 09:11:38 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1D9BZ7k007147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Feb 2012 04:11:35 -0500 Received: from springer.wildebeest.org (ovpn-116-50.ams2.redhat.com [10.36.116.50]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1D9BPTt022100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2012 04:11:34 -0500 Received: by springer.wildebeest.org (Postfix, from userid 500) id 0DA6C4A69D; Mon, 13 Feb 2012 10:11:23 +0100 (CET) Message-ID: <1329124283.2783.15.camel@springer.wildebeest.org> Subject: Re: GDB and the OpenJDK JVM From: Mark Wielaard To: Daniel Jacobowitz Cc: gdb@sourceware.org Date: Mon, 13 Feb 2012 09:11:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00034.txt.bz2 On Tue, 2012-02-07 at 14:58 -0500, Daniel Jacobowitz wrote: > Has anyone investigated non-trivial integration between GDB and this > (or any other) JVM? So far I haven't turned up anything useful. Some > examples of the sorts of integration I mean: >=20 > * Showing information about Java objects given JNI handles > * Interleaving Java frames in the stack trace > * Fabricating unwind information for JIT'd code > * Automatically handling SEGVs related to the garbage collector > without hiding SEGVs for native code For SystemTap I wrote some hotspot heap introspection functions that might be interesting. But, like Gary said, hotspot might have internal debug accessor functions that you can use too. Systemtap cannot call into the inferior so we needed some code that went through the java code heap and stack unwind "by hand": http://icedtea.classpath.org/hg/icedtea6/file/tip/tapset/jstack.stp.in If you can make inferior function calls however (and know it is safe to call them) then that will be much easier. The above systemtap tapset is somewhat fragile since it depends on a lot of hotspot code generator internals. Cheers, Mark