如何让GDB在程序计数器设为0x30时立即触发断点？

针对你遇到的问题，以下是几种可行的调试方案：

1. 用硬件观察点监视PC寄存器值 #

直接设置break *0x30无效的原因是0x30属于未映射的无效内存，GDB无法在该地址放置断点。但你可以通过监视程序计数器（PC寄存器）的值，在它被修改为0x30的瞬间触发断点——此时还未执行该地址的指令，栈结构大概率未被破坏，能正常回溯调用栈。

执行以下GDB命令：

# 确保启用硬件观察点（默认可能已开启）
set can-use-hw-watchpoints 1
# 设置观察点：当PC等于0x30时触发断点
watch $pc == 0x30

启动程序后，GDB会在PC被设置为0x30的那一刻暂停，此时你可以正常执行backtrace查看调用栈。

2. 捕获段错误信号，检查栈与寄存器状态 #

如果硬件观察点无法生效，可捕获SIGSEGV信号，在段错误触发时直接检查栈和寄存器的原始状态，手动定位问题：

# 捕获SIGSEGV信号
catch signal SIGSEGV
# 启动程序
run

触发断点后，执行以下命令排查：

• info registers：查看所有寄存器的值，重点关注rsp（栈指针）和rbp（基址指针）；
• x/20wx $rsp：查看栈顶附近的内存内容，如果是返回地址被篡改导致跳转到0x30，栈顶附近可能残留被覆盖前的有效返回地址，可手动拼接调用栈；
• x/i $rip-1：查看触发段错误前最后执行的指令（如果PC已跳转到0x30，$rip-1可能指向跳转指令）。

3. 排查栈溢出或缓冲区溢出 #

如果是局部变量缓冲区溢出覆盖了函数返回地址，导致跳转到0x30，可尝试：

• 编译时开启栈保护：添加编译参数-fstack-protector-all，让编译器在栈溢出时提前触发报错，缩小排查范围；
• 检查可疑的内存操作：重点排查涉及字符串拷贝、数组写入的代码段，确认是否存在越界访问。

4. 反向调试（限支持的GDB版本） #

如果你的Qt工具链GDB版本支持反向调试，可通过回溯执行过程找到PC被修改的位置：

# 在程序启动后创建检查点
checkpoint 1
# 运行程序直到触发段错误
run
# 回到之前创建的检查点
restart 1
# 单步反向执行，找到PC被修改的指令
reverse-stepi

注意：Windows环境下部分GDB版本的反向调试支持有限，需先确认版本兼容性。

内容的提问来源于stack exchange，提问作者Patrick Wright