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. Andrew.
