[lldb-dev] Debugging JIT-compiled code with LLVM
gclayton at apple.com
Fri Nov 19 15:29:36 PST 2010
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
>> 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
> (… 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.
> Again, thank you for being so helpful. :)
No problem, let me know if you have more questions!
More information about the lldb-dev