[lldb-dev] [LLVMdev] MCJIT debugger registration interface.

Keno Fischer kfischer at college.harvard.edu
Mon Aug 11 23:09:22 PDT 2014

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

More information about the lldb-dev mailing list