The GDB JIT Interface

Summary

GDB is great for stepping through machine code to figure out what is going on. It uses debug information under the hood to present you with a tidy backtrace and also determine how much machine code to print when you type disassemble. This debug information comes from your compiler. Clang, GCC, rustc, etc all produce debug data in a format called DWARF and then embed that debug information inside the binary (ELF, Mach-O, …) when you do -ggdb or equivalent. Unfortunately, this means that by default, GDB has no idea what is going on if you break in a JIT-compiled function. You can step instruction-by-instruction and whatnot, but that’s about it. This is because the current instruction pointer is nowhere to be found in any of the existing debug info tables from the host runtime code, so your terminal is filled with ???. See this example from the V8 docs: #8 0x08281674 in v8::internal::Runtime_SetProperty (args=...) at src/runtime.cc:3758 #9 0xf5cae28e in ?? () #10 0xf5cc3a0a in ?? () #11 0xf5cc38f4 in ?? () #12 0xf5cbef19 in ?? () #13 0xf5cb09a2 in ?? () #14 0x0809e0a5 in v8::internal::Invoke (...) at src/execution.cc:97 Fortunately, there is a JIT interface to GDB. If you implement a couple of functions in your JIT and run them every time you finish compiling a function, you can get the debugging niceties for your JIT code too. See again a V8 example: #6 0x082857fc in v8::internal::Runtime_SetProperty (args=...) at src/runtime.cc:3758 #7 0xf5cae28e in ?? () #8 0xf5cc3a0a in loop () at test.js:6 #9 0xf5cc38f4 in test.js () at test.js:13 #10 0xf5cbef19 in ?? () #11 0xf5cb09a2 in ?? () #12 0x0809e1f9 in v8::internal::Invoke (...) at src/execution.cc:97 Unfortunately, the GDB docs are somewhat sparse. So I went spelunking through a bunch of different projects to try and understand what is going on. The big picture (and the old interface) GDB expects your runtime to expose a function called __jit_debug_register_code and a global variable called __jit_debug_descriptor. GDB a...