run从头执行至断点或结束，start强制停在main()首行；start不支持重定向，传参需单引号；多次执行均重置状态；start依赖符号表，-nostdlib或高优化下可能失效。
run 和 start 都会重新启动程序，但停在哪不一样
根本区别不在“启不启动”，而在“停在哪儿”：run 从头跑，遇到断点才停，没断点就直接跑完；start 强制停在 main() 函数第一行（左大括号之后、首条语句之前），不管有没有断点。
这相当于：start ≡ break main + run，但更省一步——不用手动设断点，也不用担心 main 行号记错或被宏展开干扰。
传参方式一样，但 start 不支持重定向输入输出
run 支持完整参数组合，比如：
run --verbose -c config.txt output.log
start 虽然也接受参数（start --verbose -c config.txt），但不支持 、<code>> 等 shell 重定向语法。GDB 会把 当成普通字符串传给程序，导致 <code>argv 错乱，甚至 main 都进不去。
- 需要重定向？必须用
run - 只想快速进
main看初始化逻辑？start更干净 - 参数含空格或特殊字符？统一用单引号包裹，如
run '--flag="hello world"'
多次执行时，二者行为一致但起点不同
无论你之前用的是 run 还是 start，只要程序已停止（比如断在某处），再次敲 run 或 start 都会清空当前执行状态、从头加载程序。
关键差异仍在首次停靠点：
- 用
run后再run：仍从入口开始，停在第一个断点或结束 - 用
start后再start：仍停在main第一行，哪怕你刚在第 100 行断过 - 混用无风险，但别指望
start能“接着上次断点继续”——它永远重置
容易忽略的兼容性细节
start 依赖符号表能准确定位 main 入口。如果程序用 -nostdlib 编译、自定义入口（如 _start）、或 main 被内联/优化掉（比如 -O3 且 main 极简），start 可能报错或停在意外位置。
此时应：
- 确认调试信息完整：
file ./a.out看是否含 “with debug_info” - 降级优化：
gcc -g -O0编译再试 - 退而求其次：
break main+run，更可控
真正难处理的不是命令选错，而是 main 本身不可见——这时候 start 就只是个失效的快捷键。
