User Tools

Site Tools


gdb

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
gdb [2016/10/17 10:01] dblumegdb [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://git.dlma.com/testcode.git/|the testcode project]], make with the target "debug"
 +
 +  make debug
 +
 +If the deadlock was compiled in, then run it like so:
 +
 +  product/testcode &
 +
 +Then you can run gdb and attach to the process in one of the following ways.
 +
 +  $ gdb -p <pid-of-testcode>
 +  
 +  $ gdb product/testcode <pid-of-testcode>
 +  
 +  $ gdb
 +  (gdb) attach <pid-of-testcode>
 +  
 +
 +===== Tips =====
  
 Show all the backtraces: Show all the backtraces:
Line 12: Line 34:
   (gdb) t a a bt -3   # thread apply all backtrace top three frames   (gdb) t a a bt -3   # thread apply all backtrace top three frames
  
-==== Detecting a Deadlock ====+===== Detecting a Deadlock =====
  
 Get high level info on the threads: Get high level info on the threads:
Line 55: Line 77:
        
 Note the <nowiki>__owner</nowiki> of the mutex that thread 2 is waiting on. It's 24793. That's thread 3. There's your deadlock. Note the <nowiki>__owner</nowiki> of the mutex that thread 2 is waiting on. It's 24793. That's thread 3. There's your deadlock.
 +
 +==== 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.
 +
 +    $ /usr/local/arm/bin/arm-linux-gdb builds/myapp.sym
 +    GNU gdb (GDB) 7.5.1
 +    This GDB was configured as "--host=i686-build_pc-linux-gnu --target=arm-brcm-linux-gnueabi".
 +    Reading symbols from builds/myapp.sym...done.
 +    (gdb) set sysroot ~/Downloads/rootfs/firmware.obj/root/
 +    (gdb) set solib-search-path builds/myapp.dir/
 +    (gdb) target remote 10.15.24.54:5555
 +    Remote debugging using 10.15.24.54:5555
 +    ...
 +    (gdb) c
 +
 +===== Processing a backtrace from code =====
 +
 +When using a define like this...
 +
 +<code cpp>
 +#define PRINT_BACKTRACE { void *stack[32];                                   \
 +    const int nptrs = ::backtrace(stack, sizeof(stack) / sizeof(stack[0]));  \
 +    if (nptrs) ::backtrace_symbols_fd(stack, nptrs, STDERR_FILENO);          \
 +}
 +</code>
 +
 +You might get output like this:
 +
 +    /lib/libUILib.so(_ZN12FakeSymbolDoesNotMatterEb+0x288)[0xb3831a78]
 +    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 /proc/<pid>/maps
 +
 +    target:$ egrep " r-xp .*/(Application|libUILib.so)" /proc/$(ps -a | awk '/Application/{print $1}')/maps
 +    00010000-00dfb000 r-xp 00000000 00:0d 135649148  /bin/Application
 +    b3578000-b3f45000 r-xp 00000000 00:0d 68148928   /lib/libUILib.so
 +
 +So, for example, the first frame is at: libUILib.so + (0xb3831a78 - 0xb3578000). You can use addr2line to get that:
 +
 +    $ addr2line -e path/to/libUILib.so 0x2b9a78
 +    path/to/MySource.cpp:5712
gdb.1476723661.txt.gz · Last modified: 2023/04/12 20:44 (external edit)