From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8995 invoked by alias); 5 Jun 2012 14:24:37 -0000 Received: (qmail 8982 invoked by uid 22791); 5 Jun 2012 14:24:36 -0000 X-SWARE-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-ey0-f169.google.com (HELO mail-ey0-f169.google.com) (209.85.215.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Jun 2012 14:24:22 +0000 Received: by eaan1 with SMTP id n1so1660844eaa.0 for ; Tue, 05 Jun 2012 07:24:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.97.135 with SMTP id t7mr7654970eef.176.1338906261276; Tue, 05 Jun 2012 07:24:21 -0700 (PDT) Received: by 10.14.100.201 with HTTP; Tue, 5 Jun 2012 07:24:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 05 Jun 2012 14:24:00 -0000 Message-ID: Subject: Re: Hotspot JVM GDBJIT plugin From: Daniel Jacobowitz To: Kaushik Srenevasan Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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-06/txt/msg00029.txt.bz2 On Thu, May 24, 2012 at 7:03 AM, Kaushik Srenevasan wrote: > I've been working on a Hotspot JVM JIT plugin for GDB and noticed that > there was some interest about this earlier [1]. I currently have mixed > mode stack traces working [2] and plan to at least add file and > line number support in the future. Awesome! Thanks again for working on this. > The first of these changes [3] is a simple fix to a crash while trying to > display the return type of a JIT frame (say on 'finish'.) Does 'finish' reliably work? It seems like we'd have to get pretty lucky (in general) with the VM's implementation of stack frames. e.g. if JIT compilation triggered during an interpreted function, I wonder if it would still return to the same place. > The second (frame based symbol handler) is a feature added to help GDB > understand frames created by Hotspot's "template" interpreter. Hotspot > generates expansions for bytecodes from templates (once) into a buffer > and uses jump tables to handle dispatch. The same code range thus > corresponds to different functions, with the only differentiating > factor being metadata in stack frames. Neither ELF symbol tables nor > callbacks work in this case and hence the need for frame based symbol > resolution. > > This adds an additional callback that the reader may choose to > implement to return the name (file path or line number) of the function > executing in the frame in question. GDB's stack walk code consults this > handler if it can't find a symbol in its global symbol table. It would be nice if this code could be shared with the existing inline frame support, which returns an alternative symbol based on the frame id. -- Thanks, Daniel