应使用 break main 或 break _start：前者停在 main 函数首条汇编指令（如 push %rbp），后者停在 elf 真正入口 _start，早于 crt 初始化；若符号被 strip 或架构特殊（如 arm64/musl），需结合 info files、readelf 或 info registers rip 动态获取地址。
gdb 怎么在 main 函数第一条汇编指令处停住
不能靠 break main，它默认停在 main 函数第一行 C 代码（比如 { 或变量声明），不是真正的入口。想在程序真正开始执行的第一条汇编指令（push %rbp 或 push %ebp）就暂停，必须用地址断点。
-
break *main是最直接有效的方式：星号表示按函数符号地址下断点，GDB 会自动定位到函数起始的机器指令位置 - 如果
break *main报错（比如符号被 strip 或优化严重），可先run启动一次，等它报 “Program received signal SIGSEGV” 或直接退出前用info registers rip看当前指令地址，再break *0x...手动设 - 某些链接器（如使用
-pie或grsecurity）会导致*main地址不可靠，此时更稳妥的是用break *_start—— 这是 ELF 真正的入口，早于main，但需确认你的 libc 支持调试符号（否则_start可能不可见）
为什么 break main 不等于程序真正“刚开始”
因为 main 是 C 运行时（CRT）调用的函数，前面还有 _start → __libc_start_main → main 的调用链。break main 实际停在 __libc_start_main 调用完、刚跳进 main 的那一刻，此时栈帧已建立、argc/argv 已准备好，但全局构造函数（C++）或 .init_array 段代码可能已经执行过了。
- 想观察全局对象构造（C++）、.init/.init_array 执行、甚至 libc 初始化，必须用
break *_start或break *0x400000（具体地址查readelf -h ./a.out | grep Entry） -
start命令看似能停在main开头，但它本质是break main+run的封装，依然跳过了 CRT 初始化阶段 - 加
-g编译只是让源码行号可映射，不影响入口逻辑；而-O0能减少内联干扰，但不解决入口偏移问题
实际调试中容易忽略的兼容性细节
不同架构和 libc 版本下，入口行为有差异，硬编码地址或假设 *main 总可用会翻车。
- x86_64 下
*main通常可靠；ARM64 上部分 toolchain 会把main符号指向 PLT 入口，导致断点落在 stub 里，得改用break *&main（取地址再断） - musl libc 的
_start符号默认不导出，break *_start会失败；可用info files查 entry point 地址后手动break * - ASLR 开启时，每次
run地址都变，所以break *main是安全的（GDB 自动解析符号地址），但break *0x7ffff...这种硬地址只对当次 session 有效
main 名字，得往 ELF 入口和符号解析机制上想。
