GDB and the OpenJDK JVM

GDB and the OpenJDK JVM

[Daniel Jacobowitz]

Has anyone investigated non-trivial integration between GDB and this
(or any other) JVM?  So far I haven't turned up anything useful.  Some
examples of the sorts of integration I mean:

* Showing information about Java objects given JNI handles
* Interleaving Java frames in the stack trace
* Fabricating unwind information for JIT'd code
* Automatically handling SEGVs related to the garbage collector
without hiding SEGVs for native code

-- 
Thanks,
Daniel

Re: GDB and the OpenJDK JVM

[Gary Benson]

Hi Daniel,

Daniel Jacobowitz wrote:
> Has anyone investigated non-trivial integration between GDB and this
> (or any other) JVM?  So far I haven't turned up anything useful.  Some
> examples of the sorts of integration I mean:
> 
> * Showing information about Java objects given JNI handles
> * Interleaving Java frames in the stack trace
> * Fabricating unwind information for JIT'd code
> * Automatically handling SEGVs related to the garbage collector
>   without hiding SEGVs for native code

I don't know of anybody who has done any work in this area.  I do know
that HotSpot has a number of functions designed solely to be called by
debuggers or debug code, and it's possible that #1 and #3 are covered
that way.  None of this stuff is documented anywhere I know of so it's
worth asking on one of the HotSpot lists in case somebody can help.

Cheers,
Gary

-- 
http://gbenson.net/

Re: GDB and the OpenJDK JVM

[Daniel Jacobowitz]

On Thu, Feb 9, 2012 at 11:16 AM, Gary Benson <gbenson@redhat.com> wrote:
> Hi Daniel,
>
> Daniel Jacobowitz wrote:
>> Has anyone investigated non-trivial integration between GDB and this
>> (or any other) JVM?  So far I haven't turned up anything useful.  Some
>> examples of the sorts of integration I mean:
>>
>> * Showing information about Java objects given JNI handles
>> * Interleaving Java frames in the stack trace
>> * Fabricating unwind information for JIT'd code
>> * Automatically handling SEGVs related to the garbage collector
>>   without hiding SEGVs for native code
>
> I don't know of anybody who has done any work in this area.  I do know
> that HotSpot has a number of functions designed solely to be called by
> debuggers or debug code, and it's possible that #1 and #3 are covered
> that way.  None of this stuff is documented anywhere I know of so it's
> worth asking on one of the HotSpot lists in case somebody can help.

Thanks!  Is there a list you'd recommend?

-- 
Thanks,
Daniel

Re: GDB and the OpenJDK JVM

[Philippe Waroquiers]

On Thu, 2012-02-09 at 13:33 -0500, Daniel Jacobowitz wrote:
> On Thu, Feb 9, 2012 at 11:16 AM, Gary Benson <gbenson@redhat.com> wrote:
> > Hi Daniel,
> >
> > Daniel Jacobowitz wrote:
> >> Has anyone investigated non-trivial integration between GDB and this
> >> (or any other) JVM?  So far I haven't turned up anything useful.  Some
> >> examples of the sorts of integration I mean:
> >>
> >> * Showing information about Java objects given JNI handles
> >> * Interleaving Java frames in the stack trace
> >> * Fabricating unwind information for JIT'd code
> >> * Automatically handling SEGVs related to the garbage collector
> >>   without hiding SEGVs for native code
> >
> > I don't know of anybody who has done any work in this area.  I do know
> > that HotSpot has a number of functions designed solely to be called by
> > debuggers or debug code, and it's possible that #1 and #3 are covered
> > that way.  None of this stuff is documented anywhere I know of so it's
> > worth asking on one of the HotSpot lists in case somebody can help.
> 
> Thanks!  Is there a list you'd recommend?
> 

On google, the keywords 'java debugger interface' points at some
"standardised" documents (including a "wire protocol") aiming at
connecting a debugger to a JVM.

Philippe

Re: GDB and the OpenJDK JVM

[Daniel Jacobowitz]

On Thu, Feb 9, 2012 at 3:21 PM, Philippe Waroquiers
<philippe.waroquiers@skynet.be> wrote:
> On google, the keywords 'java debugger interface' points at some
> "standardised" documents (including a "wire protocol") aiming at
> connecting a debugger to a JVM.

That's something completely different - how to talk to the JVM for
bytecode or source level debugging of the code running on the VM.  I'm
talking about debugging the underlying JVM in order to debug native
code such as JNI.

Now, it might be possible to simultaneously control the VM using
ptrace and let enough of it free-run to speak JDWP to it.  It would be
a bit of a trick, though... I wouldn't even raise the idea if non-stop
weren't so far along.

-- 
Thanks,
Daniel

Re: GDB and the OpenJDK JVM

[Philippe Waroquiers]

On Thu, 2012-02-09 at 15:47 -0500, Daniel Jacobowitz wrote: 
> On Thu, Feb 9, 2012 at 3:21 PM, Philippe Waroquiers
> <philippe.waroquiers@skynet.be> wrote:
> > On google, the keywords 'java debugger interface' points at some
> > "standardised" documents (including a "wire protocol") aiming at
> > connecting a debugger to a JVM.
> 
> That's something completely different - how to talk to the JVM for
> bytecode or source level debugging of the code running on the VM.  I'm
> talking about debugging the underlying JVM in order to debug native
> code such as JNI.
> 
> Now, it might be possible to simultaneously control the VM using
> ptrace and let enough of it free-run to speak JDWP to it.  It would be
> a bit of a trick, though... I wouldn't even raise the idea if non-stop
> weren't so far along.
> 
I am not sure I fully understand the difference between bytecode
debugging/source level debugging of the code running on the VM
and e.g. 
>> * Showing information about Java objects given JNI handles
>> * Interleaving Java frames in the stack trace
>> * Fabricating unwind information for JIT'd code

You might also take a look at a recent version of hp wdb (hp modified
gdb). IIUC, it has some support for mixed Java and other lang debugging.
E.g. here is an extract of the manual:

  "Using WDB to examine backtraces in JavaTM thread stacks
     You can now use HP's debugger WDB 3.0.01 or later (the GNU Debugger GDB) to
     examine backtraces containing mixed language frames (JavaTM and C/C++) in JavaTM
     thread stacks. This will simplify debugging the VM and JavaTM mixed-language
     applications. Set the environment variable GDB_JAVA_UNWINDLIB to the path name
     of the JavaTM Unwind Shared Library libjunwind, which is in the JDK."

(sorry if I point again at useless info due to my misunderstanding of
your objectives).

Philippe

Re: GDB and the OpenJDK JVM

[Daniel Jacobowitz]

On Thu, Feb 9, 2012 at 4:15 PM, Philippe Waroquiers
<philippe.waroquiers@skynet.be> wrote:
>
> I am not sure I fully understand the difference between bytecode
> debugging/source level debugging of the code running on the VM
> and e.g.
> >> * Showing information about Java objects given JNI handles
> >> * Interleaving Java frames in the stack trace
> >> * Fabricating unwind information for JIT'd code

It's primarily a matter of context.  When you have a C++ debugger
attached to the JVM, also communicating with it on a socket is quite
tricky - we'd have to let the debug thread run, and hope it didn't
deadlock with some other stopped thread.  I want to expose the JVM
details while intrusively debugging the encompassing program.

Also I am not sure you can get things at the level of a JNI handle
over JWDP; those don't exist when you're looking at inside the VM.
We'd still need some way to associate the C++ jobject handles with VM
entities.

> You might also take a look at a recent version of hp wdb (hp modified
> gdb). IIUC, it has some support for mixed Java and other lang debugging.
> E.g. here is an extract of the manual:
>
>  "Using WDB to examine backtraces in JavaTM thread stacks
>     You can now use HP's debugger WDB 3.0.01 or later (the GNU Debugger GDB) to
>     examine backtraces containing mixed language frames (JavaTM and C/C++) in JavaTM
>     thread stacks. This will simplify debugging the VM and JavaTM mixed-language
>     applications. Set the environment variable GDB_JAVA_UNWINDLIB to the path name
>     of the JavaTM Unwind Shared Library libjunwind, which is in the JDK."

Yes, this is very closely related to what I want to do.  I wonder if
it requires changes to HP's JDK... I do not see references to
libjunwind outside of HP-UX.

--
Thanks,
Daniel

Re: GDB and the OpenJDK JVM

[Gary Benson]

Daniel Jacobowitz wrote:
> On Thu, Feb 9, 2012 at 11:16 AM, Gary Benson <gbenson@redhat.com> wrote:
> > Daniel Jacobowitz wrote:
> > > Has anyone investigated non-trivial integration between GDB and this
> > > (or any other) JVM?  So far I haven't turned up anything useful.  Some
> > > examples of the sorts of integration I mean:
> > >
> > > * Showing information about Java objects given JNI handles
> > > * Interleaving Java frames in the stack trace
> > > * Fabricating unwind information for JIT'd code
> > > * Automatically handling SEGVs related to the garbage collector
> > >   without hiding SEGVs for native code
> >
> > I don't know of anybody who has done any work in this area.  I do know
> > that HotSpot has a number of functions designed solely to be called by
> > debuggers or debug code, and it's possible that #1 and #3 are covered
> > that way.  None of this stuff is documented anywhere I know of so it's
> > worth asking on one of the HotSpot lists in case somebody can help.
> 
> Thanks!  Is there a list you'd recommend?

Probably this one:
http://mail.openjdk.java.net/mailman/listinfo/hotspot-dev

Cheers,
Gary

-- 
http://gbenson.net/

Re: GDB and the OpenJDK JVM

[Mark Wielaard]

On Tue, 2012-02-07 at 14:58 -0500, Daniel Jacobowitz wrote:
> Has anyone investigated non-trivial integration between GDB and this
> (or any other) JVM?  So far I haven't turned up anything useful.  Some
> examples of the sorts of integration I mean:
> 
> * Showing information about Java objects given JNI handles
> * Interleaving Java frames in the stack trace
> * Fabricating unwind information for JIT'd code
> * Automatically handling SEGVs related to the garbage collector
> without hiding SEGVs for native code

For SystemTap I wrote some hotspot heap introspection functions that
might be interesting. But, like Gary said, hotspot might have internal
debug accessor functions that you can use too. Systemtap cannot call
into the inferior so we needed some code that went through the java code
heap and stack unwind "by hand":
http://icedtea.classpath.org/hg/icedtea6/file/tip/tapset/jstack.stp.in
If you can make inferior function calls however (and know it is safe to
call them) then that will be much easier. The above systemtap tapset is
somewhat fragile since it depends on a lot of hotspot code generator
internals.

Cheers,

Mark

Re: GDB and the OpenJDK JVM

[Daniel Jacobowitz]

On Mon, Feb 13, 2012 at 4:11 AM, Mark Wielaard <mjw@redhat.com> wrote:
> For SystemTap I wrote some hotspot heap introspection functions that
> might be interesting. But, like Gary said, hotspot might have internal
> debug accessor functions that you can use too. Systemtap cannot call
> into the inferior so we needed some code that went through the java code
> heap and stack unwind "by hand":
> http://icedtea.classpath.org/hg/icedtea6/file/tip/tapset/jstack.stp.in
> If you can make inferior function calls however (and know it is safe to
> call them) then that will be much easier. The above systemtap tapset is
> somewhat fragile since it depends on a lot of hotspot code generator
> internals.

Ooh, this is very interesting.  Thanks!

Overall, I would prefer not to call into the inferior.  That's how I
feel pretty much all the time, because (A) core dumps matter a great
deal, (B) calling the inferior is fragile in its own ways, and (C)
calling the inferior is slowwwwww.  I'll do it if I have to, but I'd
rather rely on the symbol table of the JDK and manually maintained
code.

-- 
Thanks,
Daniel

Re: GDB and the OpenJDK JVM

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> I'll do it if I have to, but I'd rather rely on the symbol table
Daniel> of the JDK and manually maintained code.

The new JIT API in gdb may be what you want.  You can write a .so that
ships with the JDK that knows about JDK internals, but that plugs into
gdb.  It doesn't expose everything, but I think would be sufficient for
unwinding.

Tom

Re: GDB and the OpenJDK JVM

[Daniel Jacobowitz]

On Mon, Feb 13, 2012 at 1:56 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
>
> Daniel> I'll do it if I have to, but I'd rather rely on the symbol table
> Daniel> of the JDK and manually maintained code.
>
> The new JIT API in gdb may be what you want.  You can write a .so that
> ships with the JDK that knows about JDK internals, but that plugs into
> gdb.  It doesn't expose everything, but I think would be sufficient for
> unwinding.

Neat!  I was going to say "no, the JIT API is too limited" but I'm
glad I looked first :-)  It looks like there's no NEWS entry for
Sanjoy's work, so I missed it the first time.

I wonder if this API could be implemented in Python...

-- 
Thanks,
Daniel

Re: GDB and the OpenJDK JVM

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> I wonder if this API could be implemented in Python...

I don't see why not.  Actually, I think it can be even be done without
changing gdb, since gdb doesn't care or know what is behind the API.

If you want it to be 100% Python, you can almost do it with ctypes
callback functions; but it won't quite work since gdb needs a .so and
looks for some symbols there.

Tom