[lldb-dev] Debugging JIT-compiled code with LLVM

[Greg Clayton]

On Nov 19, 2010, at 12:59 PM, Simon Ask Ulsnes wrote:

> Thank you for your elaborate reply! I have a few small questions:
> 
>> A few questions on how this would be debugged (not worrying about the JIT
>> yet):
>> 1 - When you are debugging this, are you going to want to step through your
>> new source code files or generated C/C++ sources?
>> 2 - If you want to debug sources that you produce, will this be like
>> debugging lex/yacc code where a bunch of #line and #file directives are used
>> to map C/C++ code to your proprietary source code?
>> If you are going to be debugging standard i386/x86_64 code, then you won't
>> need to subclass lldb_private::Process.
> 
> 1) Both, ideally, but the first step will definitely be to be able to
> debug JIT'ed C/C++ code.
> 2) For my language, there is a "proper" codegen that targets the LLVM
> IR directly — no intermediate C/C++. So that's great! In the long run,
> I suppose it would be nice to support the other way as well, but
> that'll be up to the first person who needs that. ;-)
> 
>> In order to support JIT'ed code, we just need a way to communicate between a
>> running program and the debugger. Setting a breakpoint, like is done with
>> the JIT support in GDB, is quite ok for this as this is how the dynamic
>> loader plug-in for macosx currently works. We can probably get away with
>> being able to register additional dynamic loader plug-ins with the current
>> Process.
> (… examples and elaboration omitted for brevity …)
> 
> Since I'm not deeply familiar with the architecture of LLDB yet, it's
> not clear to me what the exact relationship between the classes
> Process, ProcessGDBRemote, and ProcessMacOSX is.

Process is the main class that has pure virtual functions that base classes (ProcessGDBRemote and ProcessMacOSX) would need to implement (DoLaunch, DoAttach, DoHalt, etc).


> Would it be necessary to implement the JIT support in both ProcessGDBRemote and
> ProcessMacOSX to get things working on Darwin?

We aren't supporting ProcessMacOSX right now, but later when we do, you won't need to do anything different. If we make a new dynamic loader plug-in, they are process os/vendor/arch agnostic and can be plugged into any abstract process class.

> The way the two use the DynamicLoader plugin is currently almost identical, so I'm unsure
> whether that's a temporary thing (ProcessGDBRemote should at some
> point become cross-platform, or what?).

This is hard coded for now, but we do plan on looking at the os/vendor/arch and finding an appropriate dynamic loader plug-in for the triple. In fact I can make that change soon since we already do get the triple from the process during launch or attach.

> Which one is used under normal debugging circumstances on Mac OS X?

ProcessGDBRemote (again ProcessMacOSX is currently disabled).
> 
> The rest makes sense, and I have a pretty clear idea where to go from here.
> 
>> Let me know if you need any explanation on anything mentioned above.
>> Greg
> 
> Again, thank you for being so helpful. :)

No problem, let me know if you have more questions!

Greg Clayton