Add the -g option to generate debugging symbols during compilation; 2. Use gdb to start the program and use run, backtrace, list, print and other commands to check the status; 3. Use break to set breakpoints and cooperate with condition and ignore to accurately control; 4. Use next/step/continue/finish to control the execution process; 5. Use watch to monitor variable changes and use x command to check memory; 6. Use core dump and handle signals to debug crashes and exceptions - master these core skills to efficiently locate problems, from being at a loss to being precisely repaired.

Debugging applications on Linux with GDB isn't just about running gdb ./program and hoping for the best—it's about knowing how to inspect state, control execution, and interpret what the program is really doing under the hood. Whether you're chasing a segfault, a logic bug, or just trying to understand how your code behaves, GDB is your Swiss Army knife.

Here's how to use it effectively:

1. Compile with Debug Symbols

Before anything else, make sure your program is compiled with -g :

 gcc -g -o myapp myapp.c

Without debug symbols, GDB can't map machine code back to source lines or variables—so no source browser, no variable inspection. Just raw assembly and frustration.

2. Start Debugging

Launch GDB:

 gdb ./myapp

Or if your app crashes on startup:

 gdb --args ./myapp arg1 arg2

Once inside GDB, useful first commands:

• run — start the program
• backtrace (or bt ) — show call stack when stopped
• list — show source code around current line
• print variable_name — inspect a variable
• info locals — print all local variables in current scope

If your app crashes, GDB stops at the fault. Run bt immediately—it tells you where and often why .

3. Set Breakpoints Strategically

Breakpoints stop execution so you can inspect state:

 break main
break myfile.c:42
break myfunction

Useful tricks:

• info breakpoints — list all breakpoints
• delete 1 — remove breakpoint by number
• condition 1 x > 10 — only stop if condition is true
• ignore 1 5 — skip first 5 hits of breakpoint 1

This avoids stopping every time—you focus on the interesting cases.

4. Step Through Code

When stopped at a breakpoint:

• next — step over (don't enter functions)
• step — step into functions
• continue — resume execution
• finish — run until current function returns

Use next for high-level flow; step when you suspect a function is misbehaving.

5. Watch Variables and Memory

If a variable changes unexpectedly:

 watch my_var

GDB will pause whenever my_var is modified—even deep inside a loop or another function.

For memory issues (like buffer overruns):

• x/10xw &my_array — examine 10 words in hex starting at my_array
• p &my_var — get the address of a variable
• info registers — see CPU register state

This is gold when hunting memory corruption or uninitialized reads.

6. Handle Signals and Core Dumps

If your app crashes and generates a core dump:

 gdb ./myapp core

Then run bt to see exactly where it died—even if you weren't running GDB live.

To debug signal handling (eg, SIGSEGV, SIGABRT):

 handle SIGSEGV stop print nopass

This makes GDB stop and show the signal instead of letting your program handle it silently.

Pro Tip: Use gdb -tui ./myapp for a basic text-based UI—it shows source, registers, and command line in one screen. Less tab-switching, more clarity.

GDB takes practice, but once you're comfortable, you'll debug faster than adding printf everywhere. It's not magic—it's precision.
Start small: set a breakpoint, inspect a variable, step through a loop. Build from there.
That's how you go from “Why is this broken?” to “Ah—here's exactly where.”

The above is the detailed content of Debugging Applications on Linux with GDB. For more information, please follow other related articles on the PHP Chinese website!