gdb and OpenJDK

[Erik Helin]

On 2015-02-13, Erik Helin wrote:
> 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

I just had a discussion with Staffan about this, and I just want to
clarify my comment: instead of rewriting the stack walking code in
multiple places, can we add some code in the VM that aids the
development of tools like these? We will of course require platform/tool
specific code, and probably some duplication, but how little duplication
can we get away with? gdbjit seems like it can consume a custom debug
info format, maybe we can design a very lightweight debug info format
that then can be picked up by a variety of tools (lldb, windbg, gdb,
SA, etc...)?

Thanks,
Erik

> 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