gdb and OpenJDK

[Erik Helin]

On 2015-02-12, Alexander Smundak wrote:
> It was the previous implementation that used the serviceability agent,
> sorry for the confusion. The new one replicates the necessary
> functionality of the serviceability agent instead. All the operations
> on the debuggee (catching events, reading writing to the debuggee
> memory, etc.) are performed by the GDB.
> The Python code consists of two "plugins". The first does "unwinding",
> that is, finding out the caller's frame for a given frame. JIT frames
> need unwinding because JIT code uses frame pointer as a general
> purpose register (I am speaking of x86_64), so GDB cannot unwind it.
> So the unwinding plugin locates nmethod instance containing given PC,
> fetches the frame size from it, and is thus able to locate the
> previous frame.
> The second plugin symbolizes Java frames (GDB already has the
> interface for that called FrameDecorators), and it requires sizable
> amount of code to traverse various JVM structures to do that.
> The Python module is currently about 2500 lines of code. About 10% of
> this code is platform-dependent (I have implementations for x86_64 and
> PowerPC64 and working on Aarch64).

First of all, thanks for putting work into this, having Java stacktraces in
GDB would be really helpful.

Just a quick question, instead of rewriting the stack walking code in
Python, would it be possible to use gdbjit [0]? Apparently, this is used
by LLVM MC JIT and I also think that V8 has some basic support for it.
The benefit of using something like gdbjit would be to not have the
stack walking code in multiple places:
- the vm
- SA
- Python for gdb

Thanks,
Erik

[0]: https://sourceware.org/gdb/onlinedocs/gdb/JIT-Interface.html

> Sasha
> 
> On Thu, Feb 12, 2015 at 2:14 AM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
> > Hi Jeremy,
> >
> > nice to see that somebody is working on this topic.
> >
> > Can you please detail a little bit on how this would work?
> > As far as I understand you extend gdb to support "frame undwinder"
> > plugins written in Python.
> >
> > One of these plugins, which you want to contribute to the OpenJDK, can
> > be used to unwind native Java/HotSpot stack frames by calling out to
> > the serviceability agent. Can you please explain how this could work?
> > If you debug a Java process with gdb, gdb attaches to that process
> > using "ptrace". The SA agent uses "ptrace" as well but as far as I
> > know, only once process can attach to another process at the same
> > time. So how is this callback from gdb to the SA agent supposed to
> > work?
> >
> > Regards,
> > Volker
> >
> >
> > On Wed, Feb 11, 2015 at 11:27 PM, Jeremy Manson <jeremymanson at google.com> wrote:
> >> Hey folks,
> >>
> >> I think I've mentioned to some of the people on this list that we (and by
> >> we, I mean Sasha Smundak) have been working on interoperability between gdb
> >> and Java.  Basically, what we have now allows us to get a backtrace in gdb
> >> that includes Java frames with parameter values (no local variables yet).
> >>
> >> Needless to say, this has been terribly, terribly helpful in our JVM and JNI
> >> debugging.
> >>
> >> Support for this feature is basically two parts:
> >>
> >> First, gdb needed to be extended to support the ability to plug in a frame
> >> unwinder.  The process of submitting this to gdb (which has been ongoing for
> >> quite a while) is finally starting to make reasonable progress.
> >>
> >> Next, we need a plugin for OpenJDK.  We have a plugin written that calls out
> >> to the serviceability agent.  (It's written in Python, per gdb's
> >> requirements).
> >>
> >> Pending the gdb support being finalized, we'd love to contribute the plugin
> >> to OpenJDK.    What should we do make that happen?  Write a JEP and submit
> >> it to this list?  Technically, neither of us are committers (which you need
> >> to be to submit a JEP), but I imagine we can work around that.
> >>
> >> Here's the gdb patch, for anyone interested:
> >>
> >> https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html
> >>
> >> Thanks!
> >>
> >> Jeremy