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 _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
