gdb and OpenJDK

[Erik Helin]

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.

> On 02/16/2015 10:43 AM, Volker Simonis wrote:
> > I know it's possible and I know that gdb has callbacks to consume this
> > debug information which is generated at runtime (see [1]) although
> > I've never programmed it myself. LLVM seems to use this technique and
> > has some documentation available ([2,3]). I suppose this is the
> > direction Erik wanted to go and I think that would be the right way.

Yes, this is the idea I tried to explain.

On 2015-02-16, Andrew Haley wrote:
> It would be, long term.  I've been discussing this with Red Hat's GDB
> group and I'm hoping to come up with a proposal and hopefully some
> working code.

That would be great, I would really like to see how far we can get with
a solution based on gdbjit (or something similar). Thanks for putting
time into this!

Thanks,
Erik

> Andrew.