VSCode配置launch.json启用内置GDB调试C程序遇权限及段错误定位问题咨询

错误码126的核心诱因是Linux系统自带的ptrace权限安全限制，内核配置项kernel.yama.ptrace_scope默认值为1时，普通用户无法直接附加调试自身编译的可执行程序，参照VSCode官方C++调试文档的配置要求，将该值设为0即可放开同权限进程的调试限制。
针对现有/etc/sysctl.d/10-ptrace.conf无法写入的问题，按以下步骤操作即可解决：

• 操作前提：系统目录下的配置文件所有者默认是root:root，普通用户没有修改权限，所有针对该文件的修改、权限调整操作必须全程通过sudo提权执行。之前执行chmod后仍无法写入，本质是操作逻辑存在冗余：root身份不受文件普通读写权限位限制，不需要额外给文件加可写权限，直接用sudo身份编辑文件即可完成修改。如果使用sudo执行chmod仍无法写入，大概率是SELinux/AppArmor的安全策略限制，此时无需调整文件权限，直接用sudo启动编辑器修改内容即可。
• 正确操作步骤：
  1. 确认文件基础状态：执行ls -l /etc/sysctl.d/10-ptrace.conf，正常文件权限为644，即root用户拥有写入权限，其他用户仅可读。
  2. 直接提权编辑文件：执行sudo nano /etc/sysctl.d/10-ptrace.conf，找到配置行kernel.yama.ptrace_scope = 1，将数值修改为0，保存退出。
  3. 刷新配置使其生效：执行sudo sysctl --system加载所有系统配置，再执行cat /proc/sys/kernel/yama/ptrace_scope验证返回值为0，即配置完成。

不需要永久修改全局ptrace配置为0，可通过以下方式在保障系统安全的前提下完成调试：

• 临时给GDB授予调试权限：每次需要调试前，在终端执行sudo setcap cap_sys_ptrace=eip /usr/bin/gdb，单独为GDB二进制文件开启ptrace权限，该权限重启系统后自动失效，不会长期放开系统调试限制。
• 配置VSCode自动执行预操作：在launch.json中配置preLaunchTask字段，把上述授权命令设置为调试启动前的自动执行任务，不需要每次手动在终端输入命令。
• 编译注意事项：所有需要调试的C程序，编译时必须带上-g参数，保留完整调试符号信息，VSCode的断点、变量查看、调用栈跳转功能才能正常工作。

程序触发段错误时，GDB会自动捕获SIGSEGV信号，不需要一开始就使用反汇编工具即可定位崩溃地址：

• 基础操作流程：
  1. 加载带调试符号的程序到GDB：执行gdb ./你的可执行程序路径
  2. 在GDB交互界面输入run启动程序，等程序触发段错误退出
  3. 程序崩溃后，执行info registers rip获取当前指令指针值，这个值就是触发段错误的指令地址
  4. 执行bt（backtrace）查看崩溃点的完整函数调用栈，结合源码路径映射，可直接定位到崩溃对应的源码行号。
• 反汇编工具的适用场景：只有当编译程序时未保留调试符号（未加-g参数），无法直接对应到源码行时，才需要通过反汇编工具分析崩溃位置的指令逻辑。

结合你此前使用QtSpim（MIPS指令集模拟工具）的使用经验，radare2的调试逻辑和模拟器操作逻辑有共通性，可参考以下操作流程定位段错误：

• 启动调试会话：执行r2 -d ./你的可执行程序路径，即可附加到程序运行进程上。
• 常用调试命令：
  • dc：继续运行程序，直到下一个断点或程序崩溃
  • dr rip：查看当前指令寄存器的存储值，也就是崩溃发生时的指令地址
  • dbt：查看崩溃时的函数调用栈
  • aa：自动分析程序内的符号、函数边界，辅助将崩溃地址映射到对应函数名
  • pdf @ 函数名/地址：反汇编指定位置的指令，对照崩溃地址分析触发错误的操作
• 工具选择建议：有完整源码、带调试符号的程序，GDB的源码映射效率更高；没有调试符号、需要手动分析二进制逻辑的场景，radare2的灵活度更强。

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