Changes between Version 11 and Version 12 of Debugging

Timestamp:

Sep 8, 2014, 6:07:48 AM (10 years ago)

Author:

historic_bruno

Comment:

Updates about LLDB

Debugging

@@ -32 +32 @@
 * [https://developer.apple.com/xcode/ Xcode] - free IDE for development on OS X, also has suite of debugging tools.
 * gdb
-* [http://lldb.llvm.org/ lldb] - part of the LLVM project, replacement for gdb in recent Xcode.
+* [http://lldb.llvm.org/ lldb] - part of the LLVM project, replacement for gdb in recent Xcode. LLDB equivalents for GDB commands can be found [http://lldb.llvm.org/lldb-gdb.html here].
 
 == Debugging Crashes and Assertion Failures ==
@@ -73 +73 @@
 On Linux or OS X, you won't have a crash dump, so the best tool for getting your call stack is gdb. Like Windows, you need symbols to be set up properly to make sense of what gdb tells you. If you just see a bunch of hex numbers (addresses of functions) and no names of functions, then you don't have symbols set up correctly. If you're using a release package of the game on Linux, the symbols may have been omitted to reduce the package size, but there may be an optional debug package that can be installed (e.g. on Debian and Ubuntu). Note: debug symbols do NOT require a ''debug build'' of the game. A debug build just disables optimizations to make some debugging easier, both a release build also includes debug symbols.
 
-Once you have debug symbols, if you can reproduce the crash, run the game in gdb (e.g. `gdb ./pyrogenesis`) and make it crash. Then you will return to the gdb command line. The most helpful command is `bt` to get the backtrace (call stack) at the moment of the crash. Often it's even more helpful to use `t a a bt full` to get the full backtrace of all running threads in the game. `set height 0` is useful if gdb keeps prompting you to continue, when viewing a long backtrace.
+Once you have debug symbols, if you can reproduce the crash, run the game in gdb (e.g. `gdb ./pyrogenesis`, or use [http://lldb.llvm.org/lldb-gdb.html lldb] on recent OS X) and make it crash. Then you will return to the gdb command line. The most helpful command is `bt` to get the backtrace (call stack) at the moment of the crash. Often it's even more helpful to use `t a a bt full` to get the full backtrace of all running threads in the game. `set height 0` is useful if gdb keeps prompting you to continue, when viewing a long backtrace.
 
 gdb is quite powerful and has more features than can be reasonably explained here, so check the [http://sourceware.org/gdb/current/onlinedocs/gdb/ manual] or search for tutorials. One thing you might find useful is selecting the current stack frame with `frame n`, e.g. `frame 0` is the top of the stack. Then you can use `info locals` to view local variables in that stack frame. Note that in a release build, many of these will be optimized out, or the structure may be too complex for gdb to understand.