On 2015-02-16, Andrew Haley wrote: > On 02/16/2015 12:06 PM, Erik Helin wrote: > > On 2015-02-16, 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.) > > > > Do we really need to use DWARF though? The gdbjit interface seems to > > support a custom debug format if you also implement a reader for > > your custom debug format. I've never done this, so I can't say if > > there is something missing from the gdbjit API that HotSpot requires. > > Well, it would have to be able to convey the same information as DWARF > unwinder data; the GDB people tell me that generating some DWARF is > the right way to do it. But of course I'm not wedded to any > particular format.
I agree that DWARF would be a very nice thing to have, it would (most likely) allow us to print names of variables, arguments etc in a frame. However, as you mentioned, making HotSpot output DWARF in-memory for the assembly it produces would be a massive effort. I guess what I wonder is, how little debug information can we get away with if we only want to traverse the stack and print the name of each frame? This is why I was interested in the support from gdbjit for a custom debug format. An alternative to using gdbjit, as mentioned earlier in this thread, would be to generate data structures (structs) at a well-known symbol/address that can easily be consumed from various plugins/tools. The reason for using such approach is to try to keep the maintenance work for each plugin/tool as low as possible. Thanks, Erik
