Hi All, > I think this ignores the real problem with the MCJIT debugging interface: it > doesn't give MCJIT clients any way of directly accessing and parsing the > debug metadata.
Sorry - it wasn't clear from my original post, but I'm hoping to improve debugging APIs in general, not just for the system debugger. I think there are two orthogonal concerns here - (1) the debug info format (and tools for parsing it), and (2) the APIs for getting the debug info to the people who need it. I want to keep these two things separate to allow for clients passing through debug-info or other annotations that LLVM/LLDB has no idea how to parse. So, here's a sketch of a partial solution for MCJIT clients (we'll leave the system debugger to a follow-up email): On point one, my inclination is that we should use an existing stable debug info format. Dwarf seems an obvious candidate, given the level of support in LLVM. As noted, this shouldn't matter to the client - I think there's general agreement that the debug info parsing support should be available in LLVM/LLDB. The client shouldn't have to care about debug-info format specifics unless they want to. (If anybody has a use-case where that wouldn't work, please speak up). Regarding the second point, my current (vague) plan is to introduce a utility class that, when attached to the execution engine, records the relocated debug info sections for each JIT'd object. Clients should be able to query this object to access the debug info sections. We would provide, either in LLVM or LLDB, debug info parsers that wrap this class to parse the contained debug info. My intent is that use of this API would look something like: ExecutionEngine EE = ...; DebugInfoListener DI = new DebugInfoListener(...); EE->addEventListener(DI); EE->addModule(Foo); EE->addModule(Bar); MCJITDebugInfoParser DIP = createMCJITDebugInfoParser(DI); DIP...; Any thoughts/comments on this (admittedly very vague) proposal are very welcome. Assuming it sounds reasonable so far, I'm going to start hacking up some patches and basic use cases to serve as a basis for further discussion (and a tutorial if the eventual proposal is adopted). Cheers, Lang. > On Mon, Aug 11, 2014 at 2:02 PM, David Chisnall <[email protected]> > wrote: > On 11 Aug 2014, at 18:06, Eric Christopher <[email protected]> wrote: > > > There's some support (originally forked from lldb) already in llvm to > > do this. Look at lib/DebugInfo, it's what llvm-dwarfdump, etc are > > based upon. > > Now that lldb is following trunk, it would be really great if some of this > could be unified. Every time we find a bug, we end up fixing it in both > places (sometimes we remember, sometimes we find the same bug twice). > > David > > > _______________________________________________ > LLVM Developers mailing list > [email protected] http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
