GDB quick start: Difference between revisions

From Soma-notes
 
(One intermediate revision by the same user not shown)
Line 10: Line 10:
   echo 0 > /proc/sys/kernel/yama/ptrace_scope
   echo 0 > /proc/sys/kernel/yama/ptrace_scope
   exit    # to become a regular user again
   exit    # to become a regular user again
 
  (if you try doing the attach without doing this, you'll get an error
(if you try doing the attach without doing this, you'll get an error in gdb telling you about this file)
  in gdb telling you about this file)


==Using GDB==
==Using GDB==
Line 35: Line 34:
   x = examine memory
   x = examine memory
   b = breakpoint (by line or function name)
   b = breakpoint (by line or function name)
   catch syscall = see every system call entered and exited (like strace but
   catch syscall = see every system call entered and exited
                   slower)
                (like strace, but you can see the backtrace
                   for each call)
</pre>
</pre>

Latest revision as of 16:22, 26 September 2022

Getting Started

  • Type "gdb <program>" to debug a program binary
  • Compile with -g (to get debugging symbols) (keep -O) to allow gdb to have more info about the program when debugging. But it will work without -g.
  • At the prompt type "run" to run it under gdb's control.
  • To debug an already running program, type "attach <PID>"
  • By default gdb can only attach to child processes. To allow attaching to processes that aren't gdb's children, do the following:
 sudo -i
 echo 0 > /proc/sys/kernel/yama/ptrace_scope
 exit    # to become a regular user again

(if you try doing the attach without doing this, you'll get an error in gdb telling you about this file)

Using GDB

  • For complex and interactive programs, connect in two windows/terminals
    • run the program you want to watch in one window
    • in the other, find out its pid (eg using ps aux | grep)
  • run gdb on the binary, then attach the PID ("attach <PID>")
  • set a breakpoint (probably at a function) so execution stops at a point of interest
  • do "tui enable" to get a litle text-mode interface that shows you code
  • note gdb will only follow one process at a time
    • so you have to decide whether you want to follow the parent or child on fork
    • by default, follows the parent
    • "set follow-fork-mode child" to follow child
  • remember that gdb has extensive help and command completion
    • tab is your friend!
  • Commands:
 n = next statement
 c = continue until next breakpoint/signal/program termination
 s = next statement, but going into functions
 print = view state of variables
 x = examine memory
 b = breakpoint (by line or function name)
 catch syscall = see every system call entered and exited
                (like strace, but you can see the backtrace
                 for each call)