GDB 无法用 step 进入内联函数，因其代码被复制到调用处，无独立栈帧；但可使用 break 函数名在所有展开点设断点，并用 info inline 确认是否真被内联。
GDB 无法用 step 进入内联函数，也不能靠 break 函数名 在未内联时命中——但只要编译时带调试信息且函数确实被内联了，GDB 就能定位所有展开点，只是方式和普通函数完全不同。
为什么 step 对内联函数无效
内联函数的代码被直接复制到调用处，没有独立的函数入口、没有栈帧、没有返回地址。当你在调用点执行 step，GDB 实际上会“跳过”这个逻辑块，直接走到下一行（可能是调用后的语句），而不是进入函数体。
- 这不是 GDB 的 bug，是编译器优化后程序结构的真实反映
-
next和step行为在此场景下趋于一致——都只按源码行推进，不模拟“函数调用”语义 - 即使函数声明了
inline，若编译器没实际内联（比如加了-O0或函数太复杂），step反而能进去；此时你看到的是“假 inline”，调试行为回归常规
如何确认函数是否真被内联了
别猜，用 GDB 直接查。启动后运行：
(gdb) info inline add
如果输出类似：
Inlined instances of function "add": From demo.c:5, in main at demo.c:12 From demo.c:5, in calc at demo.c:18
说明 add 已在两处展开；若提示 Function 'add' not inlined 或无输出，则它以普通函数形式存在。
- 编译时加
-Winline能辅助判断：无警告 ≈ 很可能内联；有"inlining failed"明确告诉你没内联 -
gcc -g -O2是常见触发内联的组合；-O0下基本不会内联，但调试最准确 - GCC 14 起可加
-finline-debug-info，让内联上下文更清晰（尤其对嵌套内联）
怎么给内联函数设断点并单步其内部逻辑
不能 break add 后指望停在函数定义行（demo.c:5），但可以停在它被展开的每一处：
(gdb) break add
GDB 会自动识别所有内联实例，在它们的源码位置（如 main 的第 12 行、calc 的第 18 行）同时设断点，并提示 (2 locations)。
- 运行后暂停，用
info break查看具体命中哪个位置 - 用
list或l确认当前上下文——你看到的是调用点附近的源码，不是函数定义本身 - 想逐行执行内联体内部？用
step或next都可以，只要确保光标在展开块内（GDB 会按源码行映射到对应机器指令） - 注意：变量可能显示为
<optimized out></optimized>，这是寄存器优化导致；加-Og或降低优化级可缓解
容易忽略的关键点
内联调试最常卡住的地方，不是命令不会用，而是没意识到“源码行”和“执行流”的错位：
- 同一个内联函数在不同调用点展开，GDB 把它们视为独立位置——修改一处的断点，不影响另一处
-
finish对内联无效：它依赖栈帧返回，而内联无帧可返 - 反汇编查看（
disassemble）时，你会看到函数体代码散落在各调用点附近，而非集中在一个函数节区 - 如果用了模板或宏包装内联函数，
info inline可能只显示实例化名（如max<int></int>），需核对符号名
