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.simo...@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 <jeremyman...@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
