汇编程序单独运行触发Core Dump，GDB调试时正常的原因排查

咱们直接戳破核心问题：你的手写汇编代码违反了x86-64的函数调用约定，导致参数传递错误触发段错误；而GDB的调试环境刚好“掩盖”了这个错误，所以调试时不会崩溃。

一、程序触发Core Dump的直接原因 #

先看你main函数的结尾逻辑：在boolfinal标签后直接调用了print_bool，但完全没把计算好的布尔值（存在%rax里）传递给print_bool的第一个参数。

在Linux x86-64平台上，我们遵循System V AMD64调用约定：函数的第一个参数必须通过%rdi寄存器传递。你的print_bool函数逻辑是从%rdi拿值来判断打印"true"还是"false"，但main调用它时，%rdi里是随机的垃圾值——当print_bool把这个垃圾值当作字符串指针传给printf时，访问无效内存就触发了段错误，进而生成Core Dump。

对比你给出的C代码，编译器会自动帮你处理参数传递的细节，所以C版本完全没问题。

二、为什么GDB调试时不会崩溃？ #

这是GDB调试环境的特性导致的：

• GDB会给程序添加额外的调试栈帧、符号信息，而且默认会禁用地址空间随机化（ASLR），这使得程序在调试时的内存布局和正常执行时完全不一样。
• 刚好在调试环境下，%rdi里的垃圾值指向了一块合法的内存（比如某个调试符号的字符串或者栈上的有效区域），所以printf调用没触发段错误。本质上是运气问题，不是程序真的没问题。

三、排查这类问题的实用步骤 #

1. 利用Core Dump文件定位崩溃点 #

首先确保系统允许生成Core Dump：

ulimit -c unlimited

重新运行程序生成Core Dump后，用GDB加载分析：

gdb ./asprgm core

输入bt查看调用栈，能直接看到崩溃发生在printf调用处；再用info registers查看寄存器值，就能发现%rdi是无效地址，瞬间定位问题。

2. 对比编译器生成的汇编代码 #

把你的C++代码编译成汇编，看看专业的编译器是怎么处理参数传递的：

g++ -S your_cpp_code.cpp -o cpp.s

对比cpp.s和你的手写汇编，一眼就能看出差异——编译器会严格把要传递的参数放到对应的寄存器里。

3. 手动核对调用约定 #

针对x86-64的System V调用约定，重点检查这几点：

• 函数参数是否按顺序放入%rdi、%rsi、%rdx等寄存器
• 调用函数前是否保存了需要保留的寄存器（比如%rbx、%rbp）
• 函数返回值是否正确放入%rax（这部分你做对了，但参数传递错了）

4. 在GDB中对比寄存器状态 #

在print_bool函数入口设断点：

break print_bool

分别在正常执行（通过GDB run）和直接运行程序时，查看%rdi的值——正常执行时是垃圾值，调试时是合法地址，这就能坐实问题。

四、修复你的汇编代码 #

只需要在调用print_bool前，把%rax里的计算结果移动到%rdi即可：

boolfinal:
    mov %rax, %rdi  ; 将布尔结果传递给print_bool的第一个参数
    call print_bool
    mov $0, %rax
    ret

修改后重新编译运行，Core Dump的问题就解决了。

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