gdb
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| gdb [2016/10/16 20:19] – created dblume | gdb [2024/10/22 19:07] (current) – [Attaching to a remote target] dblume | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== gdb ====== | ====== gdb ====== | ||
| + | |||
| + | ===== Example code with a deadlock ===== | ||
| + | |||
| + | Build your target with debug symbols. For example, with [[http:// | ||
| + | |||
| + | make debug | ||
| + | |||
| + | If the deadlock was compiled in, then run it like so: | ||
| + | |||
| + | product/ | ||
| + | |||
| + | Then you can run gdb and attach to the process in one of the following ways. | ||
| + | |||
| + | $ gdb -p < | ||
| + | | ||
| + | $ gdb product/ | ||
| + | | ||
| + | $ gdb | ||
| + | (gdb) attach < | ||
| + | | ||
| + | |||
| + | ===== Tips ===== | ||
| Show all the backtraces: | Show all the backtraces: | ||
| Line 5: | Line 27: | ||
| (gdb) set pagination off | (gdb) set pagination off | ||
| (gdb) thread apply all bt | (gdb) thread apply all bt | ||
| + | |||
| + | Other useful tips: | ||
| + | |||
| + | (gdb) t a a f # thread apply all frame | ||
| + | (gdb) t a a bt 3 # thread apply all backtrace bottom three frames | ||
| + | (gdb) t a a bt -3 # thread apply all backtrace top three frames | ||
| + | |||
| + | ===== Detecting a Deadlock ===== | ||
| Get high level info on the threads: | Get high level info on the threads: | ||
| Line 47: | Line 77: | ||
| Note the < | Note the < | ||
| + | |||
| + | ==== Attaching to a remote target ==== | ||
| + | |||
| + | - Deploy gdb server with the remote target. Launch remote target with gdb server. | ||
| + | - Untar remote libraries to a local dir. Eg., 487.72E04128A-2371582-rootfs.tar.gz in my ~/Downloads directory. | ||
| + | |||
| + | $ / | ||
| + | GNU gdb (GDB) 7.5.1 | ||
| + | This GDB was configured as " | ||
| + | Reading symbols from builds/ | ||
| + | (gdb) set sysroot ~/ | ||
| + | (gdb) set solib-search-path builds/ | ||
| + | (gdb) target remote 10.15.24.54: | ||
| + | Remote debugging using 10.15.24.54: | ||
| + | ... | ||
| + | (gdb) c | ||
| + | |||
| + | ===== Processing a backtrace from code ===== | ||
| + | |||
| + | When using a define like this... | ||
| + | |||
| + | <code cpp> | ||
| + | #define PRINT_BACKTRACE { void *stack[32]; | ||
| + | const int nptrs = :: | ||
| + | if (nptrs) :: | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | You might get output like this: | ||
| + | |||
| + | / | ||
| + | Application[0x4c51d0] | ||
| + | | ||
| + | You can get source code lines if you can calculate the offsets from each module. You can get those module base addresses from / | ||
| + | |||
| + | target:$ egrep " r-xp .*/ | ||
| + | 00010000-00dfb000 r-xp 00000000 00:0d 135649148 | ||
| + | b3578000-b3f45000 r-xp 00000000 00:0d 68148928 | ||
| + | |||
| + | So, for example, the first frame is at: libUILib.so + (0xb3831a78 - 0xb3578000). You can use addr2line to get that: | ||
| + | |||
| + | $ addr2line -e path/ | ||
| + | path/ | ||
gdb.1476674395.txt.gz · Last modified: 2023/04/12 20:44 (external edit)