uftrace项目中的内核符号丢失问题分析与解决

问题现象描述

在使用uftrace工具进行内核函数追踪时，用户发现大量函数被标记为"__compound_literal.1"这样的通用名称，而不是实际的函数名。这表明uftrace在解析内核符号时出现了问题，导致无法正确显示函数名称。

问题背景

uftrace是一个强大的函数调用追踪工具，能够同时追踪用户空间和内核空间的函数调用。当使用-k选项启用内核函数追踪时，uftrace依赖于内核的符号表来正确识别和显示函数名称。出现符号丢失问题时，追踪结果的可读性和实用性会大大降低。

问题分析

根据用户报告，这个问题出现在Nvidia AGX Orin平台上，使用的是Nvidia Tegra内核5.15版本。用户最初启用了KGDB（内核调试器）功能用于调试目的，但正是这个配置导致了uftrace无法正确解析内核符号。

KGDB是Linux内核的源代码级调试器，它允许开发者通过串行线或以太网连接来调试Linux内核。当KGDB启用时，它可能会改变内核符号的布局或增加额外的调试信息，这可能会干扰uftrace对内核符号的解析过程。

解决方案

用户最终通过以下步骤解决了问题：

1. 重新配置内核，禁用KGDB功能
2. 重新编译并安装修改后的内核
3. 重新运行uftrace进行追踪

这个解决方案表明，在某些特定情况下，内核调试功能可能会与函数追踪工具的符号解析机制产生冲突。禁用KGDB后，uftrace能够正确识别和显示内核函数名称。

技术建议

对于遇到类似问题的开发者，建议采取以下步骤进行排查：

1. 检查内核配置中是否有启用特殊的调试功能（如KGDB、KPROBES等）
2. 尝试使用更简单的内核配置进行测试
3. 确认uftrace版本与内核版本的兼容性
4. 检查是否有其他内核模块或功能可能影响符号表

总结

uftrace工具在内核函数追踪时依赖准确的内核符号信息。当出现符号丢失或显示为通用名称时，很可能是内核配置或环境问题导致的。通过调整内核配置，特别是禁用可能干扰符号解析的调试功能，通常可以解决这类问题。这个案例也提醒我们，在生产环境和调试环境中，内核配置可能需要不同的优化策略。