On debug symbols
Written by Mooneer Salem on Sunday 2nd of September, 2012 in General
LLVM has a facility to emit debug symbols. As you may know, debug symbols are what allow debuggers such as gdb to work. I’m happy to report that kite–llvm now emits debug symbols and allows gdb to have basic functionality:
(gdb) break exception.cpp:49
Breakpoint 1 at 0x144e609: file src/stdlib/System/exceptions/exception.cpp, line 49.
(gdb) run test_exc.kt
Starting program: /home/mooneer/kite-llvm/kite test_exc.kt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, kite::stdlib::System::exceptions::exception::throw_exception (this=0x215a2d0)
at src/stdlib/System/exceptions/exception.cpp:49
49 int num_traces = backtrace(buf, NUM_TRACE);
(gdb) bt
#0 kite::stdlib::System::exceptions::exception::throw_exception (this=0x215a2d0)
at src/stdlib/System/exceptions/exception.cpp:49
#1 0x0000000001421d7f in kite::stdlib::System::exceptions::exception::s_throw (exc=0x215a2d0)
at src/stdlib/System/exceptions/exception.h:59
#2 0x00007ffff7f48168 in __static_init____o () at test_exc.kt:2
#3 0x000000000144a31b in kite::stdlib::language::kite::kite::ExecuteCode (ast=..., context=0x215afa0,
suppressExec=false) at src/stdlib/language/kite.cpp:265
#4 0x0000000001449ff1 in kite::stdlib::language::kite::kite::ExecuteCode (ast=..., suppressExec=false)
at src/stdlib/language/kite.cpp:201
#5 0x00000000013ea54b in main (argc=1, argv=0x7fffffffe6a0) at src/apps/kite.cpp:98
(gdb) up
#1 0x0000000001421d7f in kite::stdlib::System::exceptions::exception::s_throw (exc=0x215a2d0)
at src/stdlib/System/exceptions/exception.h:59
59 static void s_throw(exception *exc) { exc->throw_exception(); }
(gdb)
#2 0x00007ffff7f48168 in __static_init____o () at test_exc.kt:2
2 (make System.exceptions.TypeMismatch())|throw;
(gdb) list
1 run [
2 (make System.exceptions.TypeMismatch())|throw;
3 ] catch [
4 __exc|print;
5 ];
(gdb)
Unfortunately, this works only on Linux (Apple’s gdb is too old, as it turns out). Eventually I want to be able to show function names/file/line numbers in exception stack traces on both OSX and Linux, but this may involve some work. Alternatively, would it be possible to automatically start gdb with the application’s current process ID immediately upon getting an unhandled exception? This might require additional debug info to be output, though.