編譯時(shí)加-g選項(xiàng)生成調(diào)試符號(hào)；2. 用gdb啟動(dòng)程序並使用run、backtrace、list、print等命令檢查狀態(tài)；3. 用break設(shè)斷點(diǎn)並配合condition和ignore精準(zhǔn)控制；4. 用next/step/continue/finish控制執(zhí)行流程；5. 用watch監(jiān)視變量變化，用x命令檢查內(nèi)存；6. 用core dump和handle信號(hào)調(diào)試崩潰和異?！莆者@些核心技巧即可高效定位問(wèn)題，從茫然無(wú)措到精準(zhǔn)修復(fù)。

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 browsing, 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.”

以上是使用GDB在Linux上調(diào)試應(yīng)用程序的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！