gdb and OpenJDK

[Erik Helin]

On 2015-02-16, Andrew Haley wrote:
> On 02/16/2015 12:06 PM, Erik Helin wrote:
> > On 2015-02-16, Andrew Haley wrote:
> >> On 02/16/2015 10:43 AM, Volker Simonis wrote:
> >>> Now if we replicate this SA code one more time in a Python library for
> >>> GDB, you'll probably agree that it can't work more reliably than the
> >>> original SA code. This may be good enough for some use cases, but it
> >>> won't be perfect. I'm not a gdb/DWARF expert but I think what we
> >>> really need is to generate debug information for all the generated
> >>> code. We need to know for every single PC of generated code the
> >>> corresponding frame information and how to get to the previous frame.
> >>
> >> It would be nice.  We don't actually need it, given that we've done
> >> without for years, and generating e.g. full DWARF unwinder data for
> >> every instruction is something that even GCC doesn't always attempt to
> >> do.  (And, of course, there's a lot of hand-written assembly code in
> >> HotSpot.  Annotating this is a significant effort.)
> > 
> > Do we really need to use DWARF though? The gdbjit interface seems to
> > support a custom debug format if you also implement a reader for
> > your custom debug format. I've never done this, so I can't say if
> > there is something missing from the gdbjit API that HotSpot requires.
> 
> Well, it would have to be able to convey the same information as DWARF
> unwinder data; the GDB people tell me that generating some DWARF is
> the right way to do it.  But of course I'm not wedded to any
> particular format.

I agree that DWARF would be a very nice thing to have, it would (most
likely) allow us to print names of variables, arguments etc in a frame.
However, as you mentioned, making HotSpot output DWARF in-memory for the
assembly it produces would be a massive effort.

I guess what I wonder is, how little debug information can we get away
with if we only want to traverse the stack and print the name of each
frame? This is why I was interested in the support from gdbjit for a
custom debug format.

An alternative to using gdbjit, as mentioned earlier in this thread,
would be to generate data structures (structs) at a well-known
symbol/address that can easily be consumed from various plugins/tools.
The reason for using such approach is to try to keep the maintenance
work for each plugin/tool as low as possible.

Thanks,
Erik