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. > On 02/16/2015 10:43 AM, Volker Simonis wrote: > > I know it's possible and I know that gdb has callbacks to consume this > > debug information which is generated at runtime (see [1]) although > > I've never programmed it myself. LLVM seems to use this technique and > > has some documentation available ([2,3]). I suppose this is the > > direction Erik wanted to go and I think that would be the right way. Yes, this is the idea I tried to explain. On 2015-02-16, Andrew Haley wrote: > It would be, long term. I've been discussing this with Red Hat's GDB > group and I'm hoping to come up with a proposal and hopefully some > working code. That would be great, I would really like to see how far we can get with a solution based on gdbjit (or something similar). Thanks for putting time into this! Thanks, Erik > Andrew.
