VS Code + GDB 远程调试中的系统库边界、跳过策略与反汇编排查

@[toc]
在这里插入图片描述

在嵌入式 Linux 远程调试中，经常会出现一种容易误判的情况：

  • 业务程序已经使用 Debug 参数构建；
  • 依赖的第三方动态库已经能够加载符号；
  • info sharedlibrary 中目标库已经显示 Syms Read = Yes；
  • 断点可以命中 main() 或业务入口；

但继续调试时仍然可能遇到：

  • 在某一行按 F11 后，VS Code 直接变成“运行中”；
  • std::string、容器、内存分配等语句无法稳定单步；
  • 点击暂停后只看到一个地址和 ??；
  • step、next、finish 报 Cannot find bounds of current function；
  • 明明已经配置了 skip，仍然会停进系统库；
  • 无法同步目标板系统库到宿主机，不知道该继续调试还是直接绕过。

这类问题说明：动态库符号加载成功，只解决了“某个库能否源码级调试”的问题，并不等于整个进程中的所有执行路径都具备源码、函数边界和行号信息。

本文重点讨论以下场景：

  1. 已确认业务程序和目标动态库可调试；
  2. 仍然无法稳定断点或源码级单步；
  3. 需要判断是否进入了系统库；
  4. 希望了解系统库如何完整调试；
  5. 无法调试系统库时，如何可靠跳过；
  6. 无法回到源码时，如何使用反汇编和指令级单步继续排查。

1. 先明确调试边界：Syms Read = Yes 只代表当前库符号已加载

执行：

1
-exec info sharedlibrary

可能看到：

1
2
3
4
5
6
From                To                  Syms Read   Shared Object Library
0x...                0x...               Yes         .../libthirdparty-core.so
0x...                0x...               Yes         .../libthirdparty-io.so
                                        No          /usr/lib/.../libstdc++.so.6
                                        No          /lib/.../libc.so.6
                                        No          /lib/.../libpthread.so.0

这里应分成两组理解：

类型 Syms Read 含义
业务程序和目标第三方库 Yes GDB 已读取可用符号，可进行函数断点、调用栈和源码级调试
libc、libstdc++、libpthread 等系统库 No 程序可以正常调用，但 GDB 缺少完整函数、源码行和局部变量信息

因此，第三方动态库全部变成 Yes 后，不需要因为系统库仍为 No 而反复重建第三方库。

真正需要继续排查的是：当前单步动作是否进入了没有符号或没有源码行信息的代码区域。

1.1 动态库已加载、符号已加载、源码可见是三件不同的事

远程调试一个共享库通常涉及三层能力：

  1. 运行库已加载：目标动态加载器已经把 .so 映射进进程；
  2. 符号已加载：GDB 能识别函数名、类型、变量或函数边界；
  3. 源码可见：GDB 记录的源码路径能够映射到宿主机上的真实源码文件。

三者关系如下：

1
2
3
4
5
6
7
flowchart LR
    A[目标进程已映射共享库] --> B{宿主机有匹配 ELF 或 debug 文件?}
    B -- 否 --> C[只能看到地址或少量动态符号]
    B -- 是 --> D[函数名和边界可识别]
    D --> E{源码路径可访问或已映射?}
    E -- 否 --> F[可看符号和汇编，但无法显示源码]
    E -- 是 --> G[完整源码级调试]

所以，看到目标第三方库 Yes，只能证明该库自身已经满足第二层；当代码调用到系统库时，调试能力会自然退化。

2. 为什么明明停在业务源码，按 F11 后却突然变成“运行中”

下面这种代码很常见：

1
2
3
4
5
6
struct CommandLineOptions {
    std::string config_path{kDefaultConfigPath};
    bool check_config{false};
    bool show_help{false};
    bool show_version{false};
};

或者：

1
const std::string argument = argv[index];

在这些位置按 F11 后，调试器可能不再停在下一行业务代码，而是进入持续运行状态。

这通常不是断点失效，而是进入了编译器生成代码、C++ 标准库内联实现或无符号系统库。

2.1 结构体声明不是运行语句

如果调试器停在：

1
struct CommandLineOptions {

不代表 CPU 正在执行“结构体定义”。

真正执行的代码通常来自：

1
CommandLineOptions options;

这条语句会调用编译器隐式生成的默认构造函数，而默认构造函数需要初始化：

1
std::string config_path{kDefaultConfigPath};

编译器生成的构造函数没有独立源码定义，DWARF 行号可能被归属到结构体首行、成员定义行或对象定义行。因此，源码指示位置有时并不直观。

实际调用关系可能是：

1
2
3
4
ParseArguments()
  -> CommandLineOptions::CommandLineOptions()
    -> std::string::basic_string()
      -> strlen / allocation / copy

2.2 一条 std::string 语句背后可能跨越多个库

1
const std::string argument = argv[index];

底层可能涉及：

  • C++ 标准库头文件中的内联模板；
  • std::string 构造函数；
  • char_traits<char>::length()；
  • strlen()；
  • operator new()；
  • malloc()；
  • memcpy()；
  • 异常处理和栈展开辅助代码。

这些代码可能分别位于：

1
2
3
4
5
业务可执行文件
libstdc++.so.6
libgcc_s.so.1
libc.so.6
编译进业务程序的标准库内联代码

如果系统库没有调试信息，GDB 在执行 step 时可能找不到下一条可用源码行，程序就会继续运行，直到：

  • 命中其他断点；
  • 回到具有源码行信息的函数；
  • 收到信号；
  • 被手动暂停；
  • 或程序结束。

2.3 F10、F11、si 和 ni 的边界

操作 GDB 命令 行为
单步跳过 next 执行当前源码行，但不主动进入当前行调用的函数
单步进入 step 尝试进入当前行调用的函数
指令单步进入 stepi / si 执行一条机器指令，允许进入 bl 调用
指令单步跳过 nexti / ni 执行一条机器指令；若为调用指令则运行到返回

对于以下语句：

1
const std::string argument = argv[index];

如果目标是调试业务逻辑，应优先使用 F10。

如果目标是分析 std::string 的实现，则需要先具备匹配的 libstdc++ 调试符号和源码，然后再使用 F11。

3. 为什么配置了 skip，仍然会进入系统库

GDB 支持为源码级单步配置跳过规则：

1
2
3
4
5
6
7
8
9
10
set step-mode off

skip -rfunction ^std::
skip -rfunction ^__gnu_cxx::
skip -rfunction ^__cxxabiv1::
skip -rfunction ^operator new
skip -rfunction ^operator delete

skip -gfile */include/c++/**/**
skip -gfile */libstdc++-v3/**/**

这些规则有效，但需要正确理解其作用范围。

3.1 skip 只改变源码级 step 的停靠策略

skip 可以告诉 GDB：

当执行 step 时，如果下一目标函数或源码文件匹配规则，就不要停在里面。

它不能：

  • 阻止 CPU 实际执行系统库；
  • 阻止业务代码调用 malloc()、strlen()、pthread_*()；
  • 让“暂停”自动回到业务源码；
  • 为缺失的 DWARF 信息补出函数边界；
  • 匹配完全未知的 ?? 函数；
  • 保证所有编译器内联代码都能被识别。

3.2 无符号的 ?? 无法按函数名跳过

如果系统库没有符号，暂停后只显示：

1
0x0000ffff... in ?? ()

此时 GDB 不知道当前地址对应：

  • std::string；
  • malloc；
  • strlen；
  • memcpy；
  • epoll_pwait；
  • 还是其他内部函数。

因此：

1
skip -rfunction ^std::

无法匹配一个名称未知的函数。

同理，skip -gfile 依赖调试信息中的源文件名；没有源码行信息时，也无法匹配。

3.3 验证 skip 是否实际加载

1
2
-exec info skip
-exec show step-mode

需要排查规则命中情况时，可临时开启：

1
-exec set debug skip on

使用完关闭：

1
-exec set debug skip off

如果 info skip 没有任何条目，说明跳过脚本根本没有加载，而不是规则本身失效。

4. 比 skip 更可靠的处理：直接运行到下一行业务代码

当某一行包含 STL、内存分配或系统调用，而 F10/F11 表现不稳定时，不必继续和系统库内部单步逻辑纠缠。

最可靠的策略是：在下一处确定的业务代码位置设置临时断点，然后继续运行。

例如：

1
2
-exec tbreak application.cpp:120
-exec continue

或者：

1
-exec advance application.cpp:120

两者的区别：

命令 特点
tbreak file:line + continue 创建一次性断点，命中后自动删除，行为直观
advance file:line 在当前栈帧范围内运行到目标位置或当前函数返回

这种方式不要求 GDB理解 std::string、malloc() 或 memcpy() 内部如何执行，只要求程序最终能回到指定业务源码位置。

对于第三方库调用，也可以使用函数断点：

1
2
-exec tbreak third_party::Runtime::OnEvent
-exec continue

这是一种比连续按 F11 更确定、更适合远程调试的工作方式。

5. 点击暂停后只看到地址和 ??，是不是又进入系统库了

通常是。

典型输出：

1
2
Thread 1 received signal SIGINT, Interrupt.
0x0000fffff7ae4740 in ?? ()

这并不说明程序异常，也不代表跳过规则失效。

5.1 “暂停”是异步冻结，不是“停到我的代码”

点击暂停的语义是：

立即停止当前正在运行的线程。

事件循环或多线程程序大部分时间可能处于：

  • epoll_pwait()；
  • poll()；
  • read()；
  • futex()；
  • pthread_cond_wait()；
  • nanosleep()；
  • 动态加载器；
  • 系统调用返回路径。

所以暂停时 CPU 在系统库，GDB 就会停在系统库。

1
2
3
4
5
6
7
flowchart TD
    A[程序运行中] --> B{暂停瞬间 CPU 在哪里?}
    B -->|业务代码| C[显示业务源码]
    B -->|第三方库且有符号| D[显示第三方库源码]
    B -->|系统库且无符号| E[显示地址和 ??]
    E --> F[查看调用栈、映射和反汇编]
    F --> G[设置业务断点后继续]

5.2 为什么此时 step 和 next 会报错

在 ?? 栈帧中，GDB 可能只知道当前 PC 地址，不知道：

  • 当前函数入口；
  • 当前函数结束地址；
  • 当前源码行范围；
  • 下一源码行；
  • 当前函数返回点。

因此执行：

1
2
3
-exec step
-exec next
-exec finish

可能得到：

1
Cannot find bounds of current function

这不是程序崩溃，而是当前栈帧没有足够的调试元数据。

5.3 暂停后正确的检查顺序

1
2
3
4
5
6
-exec info threads
-exec thread apply all bt
-exec p/x $pc
-exec info symbol $pc
-exec info proc mappings
-exec x/20i $pc-32
命令 作用
info threads 查看线程状态和当前线程
thread apply all bt 查看所有线程调用栈
p/x $pc 查看当前 AArch64 程序计数器
info symbol $pc 尝试识别当前地址对应符号
info proc mappings 判断当前地址属于哪个 ELF 或 .so
x/20i $pc-32 查看当前地址前后的汇编指令

如果调用栈上层存在业务代码或目标第三方库，可以在 VS Code 的“调用堆栈”中选择上层帧查看变量和源码。

但要注意：选择上层帧只改变观察上下文，不会把 CPU 的真实执行位置移动回该帧。

要重新进入源码级调试，应设置业务断点后继续：

1
2
-exec tbreak application.cpp:120
-exec continue

6. 暂停控制与程序退出：正确处理 SIGINT 和库内部信号

远程调试时，暂停动作通常与 SIGINT 有关。

如果应用本身把 SIGINT 当作正常退出请求，而 GDB 又配置为：

1
handle SIGINT nostop noprint pass

那么点击暂停可能变成：

1
2
3
4
5
VS Code pause
  -> GDB 产生中断
  -> SIGINT 传给应用
  -> 应用执行 shutdown
  -> 进程正常退出

调试期间更合理的设置是：

1
handle SIGINT stop print nopass

即：

  • GDB 因 SIGINT 停止；
  • 控制台打印中断信息；
  • 不把该信号继续传给应用。

如果第三方库使用某个用户信号唤醒事件循环，例如 SIGUSR1，则应配置：

1
handle SIGUSR1 nostop noprint pass

信号处理原则是：

信号角色 GDB 建议策略
调试器暂停信号 stop print nopass
第三方库内部唤醒信号 nostop noprint pass
应用正常终止信号 根据调试目标决定是否 pass

验证：

1
2
3
-exec info signals SIGINT
-exec info signals SIGUSR1
-exec info signals SIGTERM

7. 系统库能不能完整调试

可以。

GDB 并不限制进入 libc、libstdc++、libpthread 或动态加载器。要实现完整系统库源码调试，需要同时具备以下条件：

  1. 与目标板运行库完全匹配的 ELF 文件；
  2. 对应版本的独立调试符号包；
  3. 对应版本的源码；
  4. 正确的 sysroot；
  5. 正确的 debug-file-directory；
  6. 正确的 substitute-path；
  7. 运行库与调试符号的 Build ID 一致。

7.1 为什么“同名库”不能代替“同一版本库”

远程目标可能运行 Debian、Ubuntu 或厂商定制 rootfs，而宿主机交叉 SDK 可能来自 Yocto。

即使两边都存在：

1
2
3
libc.so.6
libstdc++.so.6
ld-linux-aarch64.so.1

它们也可能不是同一版本、同一配置或同一次构建。

可通过 Build ID 检查：

1
readelf -n <library> | grep 'Build ID'

只有名称相同而 Build ID 不同，不能视为可互换的调试符号来源。

使用错误系统库符号可能导致：

  • 函数边界判断错误；
  • 源码行错位；
  • 调用栈展开异常；
  • 临时断点位置错误；
  • 多线程调试行为异常。

7.2 完整系统库调试所需配置

典型 GDB 配置如下：

1
2
3
set sysroot /path/to/matching-target-sysroot
set debug-file-directory /path/to/matching-target-sysroot/usr/lib/debug
set solib-search-path /path/to/matching-target-sysroot/lib:/path/to/matching-target-sysroot/usr/lib

如果 DWARF 中记录的源码路径与宿主机源码路径不同，还需要：

1
2
set substitute-path /build/glibc-source /path/to/local/glibc-source
set substitute-path /build/gcc-source /path/to/local/gcc-source

系统库调试准备完成后，原先的：

1
0x... in ?? ()

可能变成：

1
2
3
__GI___epoll_pwait(...)
std::__cxx11::basic_string<...>::basic_string(...)
__libc_malloc(...)

并可继续进入对应源码。

8. 无法同步目标板系统库时，应该怎么处理

如果无法把目标板运行库同步到宿主机，又不打算专门分析系统库内部实现，最合理的方式不是强行使用不匹配的 SDK 系统库，而是把系统库明确当作黑盒。

推荐调试边界：

1
2
3
4
业务程序：完整源码级调试
目标第三方库：完整源码级调试
系统库：黑盒执行，不做源码级单步
无符号位置：调用栈 + 地址 + 反汇编 + 指令级调试

8.1 关闭无关系统库的自动符号加载

1
set auto-solib-add off

然后只手动加载需要调试的第三方库：

1
sharedlibrary .*libthirdparty-.*

这样可以避免 GDB 错误加载宿主机 SDK 中与目标不匹配的系统库符号。

8.2 保留跳过规则，但不要把它当作绝对保证

1
2
3
4
5
6
7
8
9
set step-mode off

skip -rfunction ^std::
skip -rfunction ^__gnu_cxx::
skip -rfunction ^__cxxabiv1::
skip -rfunction ^operator new
skip -rfunction ^operator delete
skip -gfile */include/c++/**/**
skip -gfile */libstdc++-v3/**/**

这些规则用于提升日常 F11 体验，但遇到完全无符号的 ?? 时仍然可能失效。

8.3 将“源码单步”切换为“断点驱动”

不要连续进入每一层函数，而是围绕业务边界设置断点：

1
2
3
4
-exec break application.cpp:120
-exec break runtime.cpp:260
-exec break third_party::Runtime::OnEvent
-exec continue

遇到 STL 或系统调用时：

1
2
-exec tbreak application.cpp:121
-exec continue

这比尝试跨越所有无符号调用更稳定。

9. 无法源码级调试时，使用反汇编继续分析

即使没有系统库符号，机器码仍然存在，GDB 仍然可以进行 AArch64 反汇编和指令级调试。

这是无符号环境下最可靠的兜底手段。

9.1 查看当前 PC 附近的汇编

1
-exec x/20i $pc

查看当前指令前后：

1
-exec x/40i $pc-64

典型输出：

1
2
3
4
0x0000ffff...:      mov     x0, x19
0x0000ffff...:      bl      0x0000ffff...
=> 0x0000ffff...:   ldr     x1, [x0,#8]
0x0000ffff...:      cbz     x1, 0x0000ffff...

=> 表示当前 PC 所在指令。

9.2 按地址范围反汇编

1
-exec disassemble /r $pc-64,$pc+128

/r 会同时显示原始机器码和汇编指令，适合确认：

  • bl 调用了哪里；
  • 条件跳转走了哪个分支；
  • 当前寄存器参与了什么内存访问；
  • 返回地址和栈帧是否合理。

9.3 反汇编已知函数

1
-exec disassemble application::Run

源码与汇编混合：

1
-exec disassemble /s application::Run

带原始机器码：

1
-exec disassemble /r application::Run

9.4 指令级单步

1
2
3
-exec display/i $pc
-exec si
-exec ni

含义：

  • si：执行一条指令，遇到 bl 会进入被调用函数；
  • ni：执行一条指令，遇到调用时运行到返回；
  • display/i $pc：每次停下自动显示当前指令。

当源码级 step 报函数边界错误时，可以使用 si 或 ni 继续分析。

9.5 查看 AArch64 关键寄存器

1
-exec info registers pc sp x0 x1 x2 x3 x4 x5 x6 x7 x29 x30
寄存器 常见用途
pc 当前指令地址
sp 栈指针
x0～x7 前八个整数或指针参数；x0 常兼作返回值
x29 帧指针 FP
x30 链接寄存器 LR，通常保存返回地址

查看返回地址附近：

1
-exec x/12i $x30-16

9.6 VS Code 中打开反汇编视图

程序暂停后，可通过命令面板执行：

1
Debug: Open Disassembly View

也可以在调用堆栈中右键当前栈帧打开反汇编视图。

如果当前帧为 ??，VS Code 可能无法推断函数范围，此时命令行方式更可靠：

1
2
-exec x/40i $pc-64
-exec disassemble /r $pc-64,$pc+128

10. 推荐配置：只调试业务程序和目标第三方库

下面是一套适用于“系统库不做源码调试”的配置思路。

10.1 launch.json 关键配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
{
    "name": "Remote GDB Debug",
    "type": "cppdbg",
    "request": "launch",

    "program": "${workspaceFolder}/build/application",
    "cwd": "${workspaceFolder}",

    "MIMode": "gdb",
    "miDebuggerPath": "/path/to/aarch64-cross-gdb",
    "miDebuggerServerAddress": "<target-host>:<gdbserver-port>",

    "setupCommands": [
        {
            "description": "Disable unrelated shared-library symbol loading",
            "text": "set auto-solib-add off",
            "ignoreFailures": false
        },
        {
            "description": "Locate local third-party Debug libraries",
            "text": "set solib-search-path ${workspaceFolder}/third_party/stage/usr/lib",
            "ignoreFailures": false
        },
        {
            "description": "Keep debugger interrupt inside GDB",
            "text": "handle SIGINT stop print nopass",
            "ignoreFailures": false
        },
        {
            "description": "Pass library wake-up signal",
            "text": "handle SIGUSR1 nostop noprint pass",
            "ignoreFailures": false
        },
        {
            "description": "Step over functions without source line information",
            "text": "set step-mode off",
            "ignoreFailures": false
        },
        {
            "description": "Demangle C++ symbols in assembly",
            "text": "set print asm-demangle on",
            "ignoreFailures": true
        },
        {
            "description": "Disable pagination",
            "text": "set pagination off",
            "ignoreFailures": true
        }
    ],

    "postRemoteConnectCommands": [
        {
            "description": "Load target third-party symbols",
            "text": "source ${workspaceFolder}/.vscode/load-third-party-symbols.gdb",
            "ignoreFailures": false
        },
        {
            "description": "Install system-library stepping filters",
            "text": "source ${workspaceFolder}/.vscode/skip-system-libs.gdb",
            "ignoreFailures": false
        }
    ]
}

10.2 load-third-party-symbols.gdb

1
2
3
4
5
6
7
8
9
set breakpoint pending on

tbreak main
commands
    silent
    sharedlibrary .*libthirdparty-.*
    echo Third-party shared-library symbols loaded.\n
    info sharedlibrary
end

10.3 skip-system-libs.gdb

1
2
3
4
5
6
7
8
9
10
11
12
set step-mode off

skip -rfunction ^std::
skip -rfunction ^__gnu_cxx::
skip -rfunction ^__cxxabiv1::
skip -rfunction ^operator new
skip -rfunction ^operator delete

skip -gfile */include/c++/**/**
skip -gfile */libstdc++-v3/**/**

echo System-library stepping filters installed.\n

配置完成后验证：

1
2
3
4
5
-exec info sharedlibrary
-exec info skip
-exec show step-mode
-exec info signals SIGINT
-exec info signals SIGUSR1

11. 一套可重复使用的诊断流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
flowchart TD
    A[确认业务程序和目标动态库 Syms Read = Yes] --> B[在业务代码设置断点]
    B --> C{单步是否正常?}
    C -- 是 --> D[继续源码级调试]
    C -- 否 --> E{当前行是否含 STL/系统调用/隐式构造?}
    E -- 是 --> F[优先 F10]
    F --> G{仍持续运行?}
    G -- 是 --> H[tbreak 下一行业务代码 + continue]
    G -- 否 --> D
    E -- 否 --> I[检查优化级别、DWARF 行表和源码映射]

    H --> J{暂停后是否为 ??}
    J -- 否 --> D
    J -- 是 --> K[bt + mappings + info symbol + x/i]
    K --> L{需要系统库内部实现?}
    L -- 是 --> M[准备匹配 sysroot、debug symbols 和源码]
    L -- 否 --> N[系统库黑盒处理]
    N --> O[设置业务/第三方库断点后 continue]
    N --> P[必要时 si/ni 指令级调试]

11.1 动态库前置确认

1
2
-exec info sharedlibrary
-exec sharedlibrary .*libthirdparty-.*
1
2
3
file <library>
readelf -n <library> | grep 'Build ID'
readelf -SW <library> | grep -E '\.debug_(info|line)'

11.2 单步策略检查

1
2
3
-exec info skip
-exec show step-mode
-exec show range-stepping

11.3 暂停位置检查

1
2
3
4
5
-exec thread apply all bt
-exec p/x $pc
-exec info symbol $pc
-exec info proc mappings
-exec x/20i $pc-32

11.4 确定性返回业务代码

1
2
-exec tbreak <file>:<next-line>
-exec continue

或者：

1
-exec advance <file>:<next-line>

11.5 指令级分析

1
2
3
4
-exec display/i $pc
-exec disassemble /r $pc-64,$pc+128
-exec info registers pc sp x0 x1 x2 x3 x29 x30
-exec ni

12. 常见现象速查

现象 实际原因 建议处理
目标第三方库 Syms Read = Yes 该库符号已加载 不需要继续重建该库
系统库 Syms Read = No 系统库没有对应调试符号 不调试系统库时可以接受
停在结构体声明 隐式构造函数的 DWARF 行号归属 到对象定义处调试，成员构造优先 F10
std::string 行 F11 后持续运行 进入 STL、libstdc++、libc 或内联实现 F10；或临时断点到下一行业务代码
已配置 skip 仍进入 ?? 当前函数无名称或无源文件信息 skip 无法匹配完全未知函数
点击暂停后显示地址和 ?? 暂停瞬间位于无符号系统库 查看调用栈、映射和反汇编
Cannot find bounds of current function 当前帧缺少函数边界信息 使用 si/ni，或设置源码断点后继续
点击暂停后程序退出 SIGINT 被传给应用退出处理器 handle SIGINT stop print nopass
第三方事件库反复触发 SIGUSR1 库内部唤醒机制 handle SIGUSR1 nostop noprint pass
系统库能否源码调试 可以，但必须精确匹配运行库、符号和源码 准备 sysroot、debug 文件、源码映射
无法同步目标系统库 无法可靠做系统库源码调试 系统库黑盒化，断点驱动 + 反汇编兜底

13. 核心认识

13.1 动态库可调试，不代表整个进程都可源码级单步

业务程序和目标第三方库可以具备完整 DWARF，而系统库仍然没有。执行流跨越符号边界时，调试能力会随之变化。

13.2 F11 不是“执行下一行”，而是“尝试进入当前调用”

一行业务代码可能包含多个函数调用。F11 进入哪一层，取决于编译器生成代码、内联、行号表和符号可用性。

13.3 skip 是策略，不是隔离机制

它只在 GDB 能识别函数或源文件时影响 step。它不能阻止系统库执行，也不能控制异步暂停位置。

13.4 异步暂停落在系统库是事件驱动程序的正常状态

事件循环程序大部分时间都在等待系统调用。暂停看到 epoll、futex 或 ??，不等于业务程序异常。

13.5 远程调试应从“连续单步”转向“断点驱动”

在复杂 C++、多线程、事件循环和第三方动态库场景中，临时断点、函数断点和回调断点通常比逐层 F11 更稳定。

13.6 反汇编不是最后无奈，而是调试能力的一部分

当函数边界、源码和 DWARF 不可用时，PC、寄存器、栈和机器指令仍然是可靠事实。能够在源码级和指令级之间切换，是嵌入式 Linux 远程调试的基本能力。

14. 最终建议

对于已经确认业务程序和目标第三方动态库可调试，但系统库无法准备或不值得准备的场景，推荐采用以下策略：

  1. 业务程序使用 -O0 -g3 -fno-omit-frame-pointer 构建；
  2. 目标第三方库使用同一次构建产生的未 strip Debug 文件；
  3. 只手动加载需要调试的第三方库符号；
  4. 关闭无关系统库的自动符号加载；
  5. 为 std::、C++ ABI 和标准库头文件配置 skip；
  6. STL 构造、内存分配和系统调用语句优先使用 F10；
  7. F10/F11 不稳定时使用 tbreak 或 advance；
  8. 暂停后落入 ?? 时先看调用栈和内存映射；
  9. 不在无符号帧上继续执行源码级 step/next；
  10. 必要时使用 disassemble、si、ni 和寄存器视图；
  11. 通过业务回调、状态变化和错误处理路径设置断点，而不是依赖连续单步；
  12. 只有确实需要分析 libc 或 libstdc++ 内部问题时，才投入成本准备匹配的系统库调试环境。

一句话总结：

当动态库已经具备调试符号，但断点和单步仍然异常时，应把问题从“库有没有符号”转向“当前执行流跨到了哪里、该位置是否有函数边界和源码行信息、是否应该源码级进入，以及无法进入时如何通过断点和反汇编继续推进”。

参考资料

  1. GDB Manual: Continuing and Stepping
  2. GDB Manual: Skipping Over Functions and Files
  3. GDB Manual: Signals
  4. GDB Manual: Files, sysroot and solib-search-path
  5. GDB Manual: Examining Memory
  6. GDB Manual: Machine Code
  7. VS Code: Debug C++
  8. VS Code: Configure C/C++ debugging