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

Simon Ask Ulsnes simon at ulsnes.dk
Tue Dec 21 16:20:30 PST 2010

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


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! :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jit-support-llvm-2.8.patch
Type: application/octet-stream
Size: 3016 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20101222/b0caa1a9/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lldb-jit-support.patch
Type: application/octet-stream
Size: 68522 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20101222/b0caa1a9/attachment-0001.obj>

More information about the lldb-dev mailing list