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 <David.Chisnall at cl.cam.ac.uk> wrote: > On 11 Aug 2014, at 18:06, Eric Christopher <echristo at gmail.com> 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 > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140811/8b03a489/attachment.html>
Seems reasonable to me. Thanks! -eric On Mon, Aug 11, 2014 at 11:04 PM, Lang Hames <lhames at gmail.com> wrote:> 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 > <David.Chisnall at cl.cam.ac.uk> wrote: >> >> On 11 Aug 2014, at 18:06, Eric Christopher <echristo at gmail.com> 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 >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
Yes, API wise this seems fine to me as well. On Tue, Aug 12, 2014 at 2:04 AM, Lang Hames <lhames at gmail.com> wrote:> 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 > <David.Chisnall at cl.cam.ac.uk> wrote: >> >> On 11 Aug 2014, at 18:06, Eric Christopher <echristo at gmail.com> 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 >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
A somewhat related (but also orthogonal) use case is parsing the .eh_frame and .gcc_except_table sections. .eh_frame is similar to a DWARF .debug_frame except in some small ways, so their parsers could potentially share code. Knowing how to parse these sections is valuable for frontends relying on llvm's invoke-based exception handling, and also for knowing where llvm has decided to spill callee saved registers. Having parsers for these in the llvm tree will be useful. -- Sanjoy