VxWorks：DKM / RTP / 全局符号环境

第一步不是解析 ELF，是**分清两种运行模型**：

模型	产物	执行位置	地址空间
DKM（Downloadable Kernel Module）	`.out`	内核态（supervisor mode）	与内核同一地址空间
RTP（Real-Time Process）	`.vxe`	用户态	各自独立，MMU 保护

.out 不要按 Linux .ko 直接解析。 它最特别的地方不是格式，而是符号环境：一个 DKM 是"链接到内核符号表"的，脱离目标镜像与全局符号环境看它，永远会看到一堆 unresolved symbols——那不是损坏，是模型。 </CORE RULE>

一、DKM：内核态，符号来自运行镜像

运行在 supervisor mode，可被静态链接进内核镜像，也可动态加载
.out 与内核符号表动态链接——它的外部引用指向目标镜像的全局符号环境
加载方式：目标 shell 里 ld < my_first_dkm.out（模块的 usrAppInit 随后自动运行），或经调试器 module load <path>
现场核对手段：lkup "符号名" 查符号、moduleShow / taskShow 看模块与任务
典型加载失败是 undefined symbol：DKM 调用了某个组件，而该组件在构建 VIP 内核时没被包含进去——对策是把组件加进 VIP 配置并重建 VIP（再重建 DKM），不是"修 DKM 本身"
为便于事后定位，VIP 里可打开 INCLUDE_STANDALONE_SYM_TBL（内建符号表），让崩溃/启动信息给出更有意义的调用栈

二、RTP：用户态，标准 ELF 与 `.so` 链接

每个 RTP 有独立虚拟地址空间与 MMU 保护，一个 RTP 崩溃不影响内核与其他 RTP；内核服务经系统调用进入
产物 .vxe 是标准 ELF 可执行文件；动态链接的 .vxe 按 NEEDED / SONAME / RPATH 在运行时解析 .so
可从 ROMFS/NFS/SD 卡等加载，或经调试器；也可用环境变量方式启动，例如 LD_LIBRARY_PATH=/romfs/lib 配 rtp exec ... demo.vxe &
加载失败排查路径与普通 ELF 一致：库找不到（Shared object not found，查 LD_LIBRARY_PATH 与文件系统挂载）→ 名字/版本不匹配（readelf -d 比对 NEEDED/SONAME/RPATH）→ 二级依赖断裂 → 或它本来就是静态构建的
shl / shl info 可看当前实际加载了哪些共享库
调试提示：不要在动态链接器完成符号登记之前就把调试器停住（早期暂停会看到"符号没登记"的假象）

三、全局符号环境：独立 ELF "看起来不完整"是常态

这是一个 DKM 必须整体恢复的最小集合：

VxWorks image（目标运行镜像）
 + VSB / VIP 配置
 + global symbol table（全局符号表）
 + DKM 本身
 → 再做 relocation / symbol resolution

只拿一个 DKM 单独看：大量 unresolved symbols 是预期结果，不是 malformed
反过来也成立：分析时能"解出来"的调用目标，取决于你把哪份符号环境当成真值——用错 image 的符号表，函数名会整体错位
所以 RE 主线应写成：先定位目标镜像与配置，再谈模块内的逻辑

四、"同一个 VxWorks 版本"不等于"同一个系统 ABI 环境"

SDK 本身是针对具体 VSB/VIP 生成的；DKM 也基于特定 VIP 编译，以保证与那个内核镜像的 API/ABI 兼容
因此遇到"这个 DKM 在另一台同版本 VxWorks 上为什么不工作"：优先核对具体的 image configuration，而不是只比版本字符串
同理，不要把 RTP 的 .so 当 DKM 模块加载（反之亦然）——两类产物走的是两套加载与解析机制，混用是常见错误

五、与任务/TCB 分析的接续

DKM 侧任务与内核对象仍走 re-rtos 主文档的任务表方法（taskSpawn/taskCreate + WIND_TCB 字段从上下文切换现场反推）。本分支补的是**"这份代码能不能加载、符号从哪来、跑在哪一侧"**——先解决身份与符号环境，再谈任务结构；顺序颠倒会得到一堆偏移正确但语义全错的结论。

决策树

拿到 VxWorks 目标
├─ 先分型：.out(DKM) / .vxe(RTP) / 整个 image
│    ├─ .out → 内核态：符号来自目标镜像的全局符号环境
│    ├─ .vxe → 用户态：按普通 ELF 分析；.so 走动态链接器
│    └─ image → 先提取全局符号表与配置，作为其他分析的基准
├─ 看到大量 unresolved symbol
│    ├─ 先问：我是不是只拿到了 DKM、而没拿到它的符号环境？
│    └─ 再问：目标 VIP 是否本就未包含该组件（undefined symbol 的真实成因）
├─ 模块加载不了
│    ├─ DKM → 查 VIP 组件是否包含；查与目标镜像的 ABI 是否匹配
│    └─ RTP → 查库路径/NEEDED/SONAME/RPATH/二级依赖/是否静态构建
├─ 同版本却行为不同
│    └─ 核对 image configuration（VSB/VIP）而不是版本字符串
└─ 确认身份与符号环境之后 → 再进任务表/TCB 分析（[[re-rtos]] 主文档方法）

工具与验证

现场枚举：lkup（符号）、moduleShow（模块）、taskShow（任务）、shl / shl info（已加载共享库）
加载：ld < module.out（DKM）、rtp exec ... demo.vxe（RTP）
ELF 侧：readelf -d（NEEDED/SONAME/RPATH 比对）、常规符号与重定位工具
配置侧：VSB / VIP 配置与 image 构建产物（决定符号环境与组件集合）
验证：能同时说清「模型（DKM/RTP）+ 目标 image 与配置 + 符号解析依据 + 加载路径」

该平台的坑（汇总）

把 DKM .out 当 Linux .ko 直接解析：执行模型、符号模型、加载机制都不同
只看单个 DKM 就判断"文件不完整/被裁剪"：它是链接到目标镜像符号环境的，孤立看必然一堆未解析符号
undefined symbol 时去改 DKM：真实成因通常是 VIP 未包含该组件，要改的是镜像配置并重建
用错 image 的符号表：函数名会整体错位，比"没有符号"更危险
拿版本号当 ABI 兼容性依据：SDK 与 DKM 都针对具体 VSB/VIP 生成，要核对配置
把 RTP 的 .so 当 DKM 模块加载（或反之）：两套加载/解析机制不可混用
在动态链接器完成符号登记前就下结论：早期暂停会看到"符号没登记"的假象
跳过身份与符号环境直接做任务/TCB 分析：会得到偏移正确但语义全错的结论

6.4 KiB Raw Blame History Unescape Escape