gdb and OpenJDK

[Dmitry Samersoff]

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.