Re: Hotspot JVM GDBJIT plugin

[Daniel Jacobowitz <drow@false.org>]

On Thu, May 24, 2012 at 7:03 AM, Kaushik Srenevasan <kaushik@twitter.com> 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