drgn项目v0.0.31版本发布:调试信息查找机制全面升级
2025-06-25 18:28:40作者:温艾琴Wonderful
项目简介
drgn是一个功能强大的调试器工具,专为Linux内核和用户空间程序调试而设计。它提供了Python接口,允许开发者以编程方式检查运行中的系统或核心转储文件的状态。与传统的调试器不同,drgn不需要在被调试系统中安装任何额外组件,这使得它特别适合生产环境的问题诊断。
版本亮点
本次发布的v0.0.31版本是自项目初始版本0.0.1以来最重要的更新之一,带来了多项重大改进和新功能,特别是在调试信息查找机制方面进行了全面重构。
核心改进
调试信息查找机制重构
本次版本对drgn查找调试符号的方式进行了彻底重写,引入了全新的模块概念和控制机制:
-
新增模块类型类:
drgn.MainModule:主程序模块drgn.SharedLibraryModule:共享库模块drgn.VdsoModule:VDSO模块drgn.RelocatableModule:可重定位模块drgn.ExtraModule:额外模块
-
增强的模块管理API:
- 新增了
modules()、loaded_modules()等方法用于查询和操作程序加载的模块 - 提供了
create_loaded_modules()等方法用于手动覆盖drgn的自动检测结果
- 新增了
-
调试信息查找控制:
- 新增
drgn.Program.debug_info_options属性用于控制调试信息查找行为 - 命令行工具增加了
--try-symbols-by、--no-symbols-by等选项 - 新增了
register_debug_info_finder()等方法用于注册自定义调试信息查找器
- 新增
-
日志增强:
- 现在会记录查找模块和调试符号的完整过程
- 使用
--log-level debug选项可以查看详细日志
调试符号匹配更严格
为了提高准确性,新版本对用户提供的调试符号文件实施了更严格的匹配规则(基于构建ID)。这一变化虽然提高了可靠性,但也带来了不兼容性:
- 不匹配任何加载模块的符号文件将被忽略并发出警告
- 如需强制使用特定文件,需要通过
try_file(path, force=True)明确指定 - 完全独立于加载模块的调试符号可通过
--extra-symbols选项加载
内核模块调试改进
不再强制要求depmod(8)元数据来查找Linux内核模块的调试符号(但仍会作为优化手段使用)。这一改进简化了内核模块调试的准备工作。
新功能与增强
-
debuginfod集成改进:
- 添加了下载调试符号时的进度条显示
- 支持从debuginfod下载内核调试信息(目前主要针对Fedora Linux内核)
-
插件系统:
- 新增插件架构,允许通过钩子扩展程序初始化过程
- 插件可以注册调试信息查找器、对象/类型/符号查找器等
-
DWARF支持增强:
- 新增对DWARF导入单元和
gnu_debugaltlink文件的支持 - 这些特性被某些Linux发行版使用
- 新增对DWARF导入单元和
-
命令行增强:
- 新增
-e选项支持直接从命令行运行代码片段 - 改进对非终端标准输入的处理
- 新增
-
堆栈跟踪改进:
- 即使没有完整的调试信息,
drgn.StackFrame.name也能提供更有用的信息 - 支持在没有调试符号文件的情况下使用ORC进行内核堆栈展开
- 修复了AArch64平台上NULL函数指针调用的展开问题
- 即使没有完整的调试信息,
-
新辅助函数:
- 新增
drgn.helpers.linux.kthread模块,提供内核线程相关辅助函数 - 新增
kernfs_parent()和kernfs_root()辅助函数
- 新增
兼容性更新
-
Linux内核支持:
- 新增对Linux 6.14和6.15的支持
- 更新了内核模块支持以兼容Linux 6.14
- 更新了文件系统和kernfs辅助函数以兼容Linux 6.15
-
平台特定修复:
- 修复了CentOS/RHEL 9内核上的
task_cpu()和堆栈跟踪问题 - 改进了AArch64平台的支持
- 修复了CentOS/RHEL 9内核上的
错误修复
-
核心功能修复:
- 修复了
-s选项在用户空间程序中的地址查找问题 - 修复了调试符号下载的中断处理(支持Ctrl-C)
- 修复了
kmodify.call_function()的类型检查和符号扩展问题
- 修复了
-
DWARF处理改进:
- 修复了中间包含
DW_OP_addr操作的DWARF表达式处理 - 新增对
DW_CFA_GNU_args_size操作的支持
- 修复了中间包含
-
稳定性增强:
- 修复了无效DWARF信息解析时的内存安全问题
- 修复了
del prog.language操作导致的段错误 - 改进了对非标准核心转储文件的处理
文档与教程
-
新增交互式教程:
- 提供了详细的blk_rq_qos崩溃分析教程
- 配套视频帮助用户快速上手
-
文档改进:
- 全面更新了获取调试符号的文档
- 新增man page参考手册
- 替换了文档中不兼容的
which命令用法
总结
drgn v0.0.31版本通过重构调试信息查找机制、增强debuginfod集成、新增插件系统等重大改进,显著提升了调试体验和灵活性。特别是对内核模块调试和堆栈跟踪的改进,使得在生产环境中诊断复杂问题变得更加容易。虽然引入了一些不兼容的变化,但这些改变总体上提高了工具的可靠性和用户体验。
登录后查看全文
热门项目推荐
相关项目推荐
GLM-5智谱 AI 正式发布 GLM-5,旨在应对复杂系统工程和长时域智能体任务。Jinja00
GLM-5-w4a8GLM-5-w4a8基于混合专家架构,专为复杂系统工程与长周期智能体任务设计。支持单/多节点部署,适配Atlas 800T A3,采用w4a8量化技术,结合vLLM推理优化,高效平衡性能与精度,助力智能应用开发Jinja00- QQwen3.5-397B-A17BQwen3.5 实现了重大飞跃,整合了多模态学习、架构效率、强化学习规模以及全球可访问性等方面的突破性进展,旨在为开发者和企业赋予前所未有的能力与效率。Jinja00
Kimi-K2.5Kimi K2.5 是一款开源的原生多模态智能体模型,它在 Kimi-K2-Base 的基础上,通过对约 15 万亿混合视觉和文本 tokens 进行持续预训练构建而成。该模型将视觉与语言理解、高级智能体能力、即时模式与思考模式,以及对话式与智能体范式无缝融合。Python00
MiniMax-M2.5MiniMax-M2.5开源模型,经数十万复杂环境强化训练,在代码生成、工具调用、办公自动化等经济价值任务中表现卓越。SWE-Bench Verified得分80.2%,Multi-SWE-Bench达51.3%,BrowseComp获76.3%。推理速度比M2.1快37%,与Claude Opus 4.6相当,每小时仅需0.3-1美元,成本仅为同类模型1/10-1/20,为智能应用开发提供高效经济选择。【此简介由AI生成】Python00
Qwen3.5Qwen3.5 昇腾 vLLM 部署教程。Qwen3.5 是 Qwen 系列最新的旗舰多模态模型,采用 MoE(混合专家)架构,在保持强大模型能力的同时显著降低了推理成本。00- RRing-2.5-1TRing-2.5-1T:全球首个基于混合线性注意力架构的开源万亿参数思考模型。Python00
项目优选
收起
deepin linux kernel
C
27
11
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
570
3.84 K
Ascend Extension for PyTorch
Python
380
454
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
894
677
暂无简介
Dart
803
198
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
353
207
昇腾LLM分布式训练框架
Python
119
147
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
12
1
🔥LeetCode solutions in any programming language | 多种编程语言实现 LeetCode、《剑指 Offer(第 2 版)》、《程序员面试金典(第 6 版)》题解
Java
68
20
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
1.37 K
781