7.7实时内核调试支持

7.7 实时内核调试支持

在 menuconfig 过程中，我们可以看到 Cobalt 实时内核的配置选项，其中有一个 Debug support 配置项集合，如下图所示：

其中，部分配置项已经在其它章节中介绍过，这里介绍一下剩余的选项。

7.7.1 Cobalt 实时内核支持的断言

[*] Xenomai/cobalt ---> [*] Debug support ---> [*] Cobalt runtime assertions 对应 CONFIG_XENO_OPT_DEBUG_COBALT [*] Check for calling context 对应 CONFIG_XENO_OPT_DEBUG_CONTEXT [*] Spinlock debugging support 对应 CONFIG_XENO_OPT_DEBUG_LOCKING

上述 3 个内核配置项各自对应不同的子系统调试<subsys>：COBALT/CONTEXT/LOCKING。打开上述配置项后，Cobalt 实时内核在运行时支持的断言不仅包括各自特有的断言，还包括一些通用断言。

7.7.2 Cobalt 实时内存对用户态软件调试支持

[*] Xenomai/cobalt ---> [*] Debug support ---> [*] User consistency checks 对应 CONFIG_XENO_OPT_DEBUG_USER [*] Detect relaxed mutex owner 对应 CONFIG_XENO_OPT_DEBUG_MUTEX_RELAXED [*] Detect sleeping with mutex 对应 CONFIG_XENO_OPT_DEBUG_MUTEX_SLEEP [*] Detect usage of legacy constructs/features 对应 CONFIG_XENO_OPT_DEBUG_LEGACY

1. Detect relaxed mutex owner

为了避免遭受意外的延迟，CONFIG_XENO_OPT_DEBUG_MUTEX_RELAXED 选项打开后，支持如下 2 种场景的检测。

• 当线程尝试获取被其他处于secondary/relaxed模式的线程持有的互斥锁时，检测到潜在优先级反转风险（持有者处于非实时模式）
  • 如果实时线程启用了开启了调试通知（XNWARN），则向实时线程发送 SIGDEBUG 信号。
• 当线程持有boosters（优先级继承或保护对象）的线程即将进入宽松模式时：
  • 遍历该线程持有的所有同步对象
  • 检查每个等待队列中的线程
  • 对开启调试通知（XNWARN）的等待线程发送SIGDEBUG信号

上述 2 种场景，都依赖线程的 XNWARN 调试标志，即 PTHREAD_WARNSW 标志。此标志默认关闭，可以通过 pthread_setmode_np(0, PTHREAD_WARNSW, NULL) 开启。具体可以参考前面的章节。

最后，注意该内盘配置选项在实时模式下对存在竞争的互斥锁操作会有一定性能开销，不建议在生产环境中使用。

2. Detect sleeping with mutex

内核配置选项 CONFIG_XENO_OPT_DEBUG_MUTEX_SLEEP 用于检测线程持有互斥锁（mutex）时进入睡眠状态的情况。这种情况会导致其他等待该锁的线程被阻塞，可能引发优先级反转问题，破坏实时性。

当线程持有 mutex 并尝试进入睡眠时（如调用sleep类函数），如果实时线程启用了开启了调试通知（XNWARN），则向实时线程发送 SIGDEBUG 信号。

该选项在实时模式下会产生显著性能开销，不建议在生产环境中使用。

3. Detect usage of legacy constructs/features

实时应用程序可以通过以下两种方式打开 RTDM 设备。

推荐的使用方式，Xenomai 应用程序使用实际的设备节点路径来打开RTDM设备。例如：

fd=open("/dev/rtdm/devname",...);

这种方法不仅符合最新的命名规范，还能避免潜在的兼容性问题和警告信息。

XENO_OPT_RTDM_COMPAT_DEVNODE是一个布尔类型的配置选项，位于drivers菜单下。其默认值为y，表示启用。该选项允许应用程序在打开RTDM设备时使用旧的命名方案。

• fd = open("devname", ...);
• fd = open("/dev/devname", ...);

当应用程序使用上述旧命名方案打开RTDM设备时，如果内核配置中启用XENO_OPT_DEBUG_LEGACY，Xenomai 会在内核日志中发出警告信息。

7.7.3 打印用户/内核空间 trap 信息

[*] Xenomai/cobalt ---> [*] Debug support ---> [*] Cobalt runtime assertions 对应 CONFIG_XENO_OPT_DEBUG_COBALT [*] User consistency checks 对应 CONFIG_XENO_OPT_DEBUG_USER

Cobalt 实时内核在handle_oob_trap_entry函数中处理实时线程在用户/内核空间产生的异常事件。在此期间，会根据编译选项 CONFIG_XENO_OPT_DEBUG_* 控制区分内核空间和用户空间异常，并打印警告信息，包含线程名、陷阱号、指令指针和 PID 等信息。

• 当异常发生在内核空间的示例 (CONFIG_XENO_OPT_DEBUG_COBALT启用时)

[Xenomai] switching rt_thread-1 to secondary mode after exception #13 in kernel-space at 0xffff000012345678 (pid 8912)

• 当异常发生在用户空间的示例 (CONFIG_XENO_OPT_DEBUG_USER启用时)

[Xenomai] switching can_rx_task to secondary mode after exception #14 from user-space at 0x000055aa12345678 (pid 7345)

7.7.4 Spinlock debugging support

[*] Xenomai/cobalt ---> [*] Debug support ---> [*] Spinlock debugging support 对应 CONFIG_XENO_OPT_DEBUG_LOCKING

CONFIG_XENO_OPT_DEBUG_LOCKING 选项打开后，Cobalt 实时内核会在运行时统计各CPU核心在实时调度中的 spinlock 竞争情况。对于找到因为中断关闭造成的延迟过长的问题，非常有用。

cat /proc/xenomai/debug/lock命令触发lock_vfile_show函数，输出 spinlock 的信息。

CPU0: longest locked section: 1588352 ns spinning time: 1572768 ns section entry: kernel/xenomai/pipeline/intr.c:28 (xnintr_core_clock_handler) CPU1: longest locked section: 1499043 ns spinning time: 832238 ns section entry: kernel/xenomai/pipeline/intr.c:28 (xnintr_core_clock_handler) CPU2: longest locked section: 4771309 ns spinning time: 7154 ns section entry: kernel/xenomai/pipeline/intr.c:28 (xnintr_core_clock_handler) CPU3: longest locked section: 19885575 ns spinning time: 4001 ns section entry: kernel/xenomai/pipeline/tick.c:79 (proxy_set_next_ktime)

以 CPU0 为例，各字段的含义如下：

CPU0: longest locked section: 1588352 ns # 该CPU上最长锁持有时间(1.58ms) spinning time: 1572768 ns # 自旋等待锁的总时间(1.57ms)??? section entry: xnintr_core_clock_handler # 最长锁发生在时钟中断处理函数