调试Pintool时触发SIGTRAP信号问题求助

以下是针对你遇到的GDB触发SIGTRAP, Trace/breakpoint trap问题的常见排查和解决步骤：

1. 解决Pin与GDB的断点冲突 #

Pin在插桩过程中会自行插入断点指令（INT3）控制执行流程，这会和GDB设置的断点产生冲突，导致意外触发SIGTRAP。

• 启动Pin时添加-pause_tool 1参数，让Pin在初始化阶段暂停，等待调试器attach：

  pin -pause_tool 1 -t champsim_tracer.so -- [你的目标程序]
  

• 通过ps aux | grep pin找到Pin进程ID，再用GDB attach：

  gdb -p [Pin进程ID]
  

• 在GDB中设置断点后执行cont继续运行。

2. 确保Pintool编译时包含调试符号 #

如果编译Pintool时未生成调试信息，GDB无法正确映射代码行到内存地址，可能导致断点异常：

• 重新编译Pintool，添加-g参数生成完整调试符号，同时可添加-O0关闭编译优化避免代码被精简。
• 在GDB中执行info line champsim_tracer.cpp:160，检查是否能关联到代码行对应的内存地址。若提示找不到该行，说明调试符号缺失或代码被优化，需重新编译调整参数。

3. 排查SIGTRAP的具体来源 #

触发SIGTRAP后，先确认信号来源：

• 在GDB中执行bt查看调用栈，判断是Pin内部逻辑触发的断点，还是你设置的断点生效。
• 如果是Pin内部的SIGTRAP，可临时设置GDB忽略该信号的停止行为（注意不要影响自身断点）：

  handle SIGTRAP nostop pass
  

  之后重新执行break champsim_tracer.cpp:160激活自定义断点。

内容的提问来源于stack exchange，提问作者Taiga Imai