Andrew, One of possible solution is to make gdb to support native plugins, than re-use existing hotspot code as much as possible.
I have a patch for gdb and can send it across if anybody interesting in it. With this patch we can do something like: (gdb) load-plugin libgdbjvm.so (gdb) attach PID (gdb) jvm show <whatever you implement within libgdbjvm.so> -Dmitry On 2015-02-16 13:52, 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.) > >> 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. > > 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. > > Andrew. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
