• TipsAndTricksTodo

Suggestions for Tips and Tricks to add

This is page is just a wish list. If you want to write one (thanks!), create a new page for it, or if it's small enough maybe it's a better fit for the FAQ. Currently, links to new pages are added to HomePageUsingColumn. If we face the problem of having too many such links there that's a good problem to have :-), and we can reorganize then. Once an entry is written, please remove the entry from here.

1. Debugging a segv

• Some users aren't sure what to do next.

2. Apropos Is Your Friend

• Some good examples to drive this point home.

3. GDB can't find my source files

• set source search directory
• include description of (in user-speak) distinction between DW_AT_comp_dir and DW_AT_name

4. Working with core files

5. Breakpoints

• conditional
• thread specific
• saving complex breakpoint specifications across sessions
• use of $_streq in a conditional breakpoint
• breakpoint commands

6. Watchpoints

• h/w watchpoints let the program run at speed (some users are surprised when I tell them this)
• watch -l

7. Pretty-printers

• cut-n-paste example?
• doc links
• how can a pretty-printer cache local state?

8. python api

There's got to be some good tips and tricks here.

9. catch syscall, etc

• e.g., watching for a particular file to be opened

10. ELF, DWARF

• Some questions from users can be answered with objdump -h, et.al.
• Other questions can be answered with some understanding of debug info (e.g. why can't gdb print a variable's value, or some such)
• Links to ELF, DWARF docs?

11. ABIs

• Knowledge of an ABI can often help debug when there's insufficient or incorrect debug info.
• Links to some ABIs?

12. all-stop vs non-stop

• threads in general?
• example of starting inferior in separate xterm/tty (for non-stop case)

13. debugging optimized code

• issues

14. tracepoints

• tracepoints don't get enough love, maybe some useful examples?

15. How GDB lies to you

Although GDB tries to present an accurate picture of what your program is doing, that doesn't always happen. Sometimes this is because your program has corrupted state, sometimes it's because the debugging information is missing or wrong, and (occasionally) GDB itself has bugs.

At the beginning of a function, function arguments may be reported incorrectly. You'll know this is happening because if you step by a line or two and look again, the function arguments now look correct. (This is because it usually takes multiple instructions to set up a stack frame - if you stop in the middle of this process, you'll see garbage.)

If your program scribbles on the stack, GDB will do its best, but your backtrace is not going to reflect reality. If you're lucky, you won't see anything, if you're unlucky, it will be subtly wrong.

GDB does lots of stuff behind your back. For instance, when your program raises a signal, GDB gets control for a moment, then silently lets your program continue, but the extra time delay can affect your program's behavior. Similarly for breakpoints.

16. hardcore: stack reconstruction

• if core was generated for program using different libc version and gdb can't unwind through restore_rt

• recovering from bad backtrace from segv from bad indirect branch
• not always possible, but sometimes

17. Running the inferior in another tty

It's often nice to have the inferior run in another tty from gdb. However, it's also often easiest to start the inferior from gdb (and thus from gdb's tty). GDB has a "tty" command to set the inferior tty. Plus one might be able to have a wrapper that starts the inferior in another tty.