[lldb-dev] I implemented some support for JIT compiled code in LLDB.

[Greg Clayton]

Simon, 

Most of the LLDB team is out for holiday vacation, we will try and get this patch looked at as soon as possible when we return in the new year!

Sorry for the delay,

Greg Clayton

On Dec 21, 2010, at 6:20 PM, Simon Ask Ulsnes wrote:

> Hey list,
> 
> Under the competent guidance of Greg Clayton, I managed to get JIT
> support working in LLDB on Mac OS X. I have a patch set with my
> changes, but I'm unsure how to proceed to get this completely
> finished.
> 
> Remarks:
> 
> 1) Many parts of LLDB assume the existence of an on-disk object file
> and optionally symbol file. Many of my changes are simply shortcuts to
> get around this assumption, and they include a few hacks. It would be
> very nice to be able to abstract the general interfaces of LLDB to
> better support the use case where there is no debug information on
> disk, but only in memory.
> 
> 2) My solution does not include support for DWARF debug information
> yet. This is mainly because LLVM doesn't yet include DWARF information
> for JIT'ed code, except for exception handling frames. It also doesn't
> include source code information, since that would require a bit more
> work on the LLVM side of things.
> 
> 3) My solution depends on a small patch to LLVM. The current JIT
> debugging support in LLVM is made for GDB, and ironically it *only*
> supports DWARF information. I added a few fields, so that the
> communication from LLVM to LLDB consists of { symbol_name,
> function_start, function_end }, which is enough to provide some useful
> information in backtraces, but it would be very nice with full DWARF
> support. I'm unsure how to proceed from here.
> 
> 4) I have had to make several minor changes to the existing LLDB code
> to avoid some crashes, which I presume arise from the fact that
> certain unguaranteed assumptions no longer hold (for instance, a
> Process can now hold multiple DynamicLoader plugins). I'm not sure
> what the full implications of those changes are. I'm also doing things
> I don't fully understand in several places, such as choosing arbitrary
> values for user_t and UUID values. Can someone tell me if I'm doing
> something wrong and why?
> 
> 5) Since listening for JIT code emissions requires setting a
> breakpoint in a function, which in turn requires loading symbol
> information, it would be nice to make the JIT support dependent on a
> command-line switch a la ./lldb --jit. Otherwise it takes several
> seconds to launch a binary that has lots of symbols, such as any
> executable that loads LLVM. Also, I'm not sure if my patch works with
> a binary that loads LLVM as a dynamic library at runtime.
> 
> 6) I have no clue how to write tests for this feature. Any ideas or
> pointers on how this should be done? When I run test/dotest.py, I get
> a crash on "pure virtual method called".
> 
> The attached patches are written against LLVM RELEASE_2_8 and LLDB
> revision 122352.
> 
> I hope this is useful — it's already very useful to me in debugging my
> own JIT compiler code. :)
> 
> Happy Holidays all around! :)
> 
> Sincerely,
> Simon
> <jit-support-llvm-2.8.patch><lldb-jit-support.patch>