Adds support for kernel symbol dumping via kallsyms

[Godones]

Introduces infrastructure to extract, store, and expose kernel symbol information, enabling access via a dedicated procfs file. Integrates kallsyms section in the linker script, a build script for symbol extraction, and updates the build process to automate symbol generation.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR adds kernel kallsyms generation + exposure via /proc/kallsyms by reserving a .kallsyms linker section and wiring a post-build script into the Starry build pipeline.

Changes:

• Inject a new post-build step (starry-kallsyms.sh) into Starry’s cargo config patching.
• Reserve a .kallsyms section in the linker script and initialize a KallsymsMapped in procfs, exposing it as /proc/kallsyms.
• Generalize SeqFile producers to return different content types (bytes, strings, static refs) via a new trait.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
scripts/axbuild/src/starry/build.rs	Injects kallsyms post-build command and adds tests for ordering vs uImage generation.
scripts/axbuild/scripts/starry-kallsyms.sh	New script to generate kallsyms and patch the kernel ELF using rust-binutils + ksym tooling.
os/StarryOS/starryos/ext_linker.ld	Adds a reserved .kallsyms section and exports start/end symbols.
os/StarryOS/kernel/src/pseudofs/proc.rs	Reads kallsyms blob from linker-reserved region, initializes global mapping, and exposes /proc/kallsyms.
os/StarryOS/kernel/src/pseudofs/file.rs	Adds SeqFileContent trait to support more return types for sequential files.
os/StarryOS/kernel/Cargo.toml	Adds the ksym dependency to support kallsyms parsing/mapping.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mai-team-app]

PR #837 审核：内核符号导出（kallsyms）支持

变更概述

本 PR 为 StarryOS 引入了 /proc/kallsyms 支持，包含以下组件：

1. 链接脚本（ext_linker.ld）：在 .data 段后新增 .kallsyms 段，预留 8MB 空间用于存储内核符号表。构建后由 rust-objcopy --update-section 写入实际数据。
2. 构建脚本（starry-kallsyms.sh）：新增 post-build 步骤，使用 rust-nm 提取内核符号，过滤后通过 gen_ksym 生成二进制符号表，再用 rust-objcopy 注入 ELF。
3. 构建集成（build.rs）：在 patch_starry_cargo_config 中注入 kallsyms post-build 命令，确保在 uImage 生成之前执行（顺序正确）。
4. 内核初始化（proc.rs）：在 procfs builder 中读取 .kallsyms 段数据，初始化 KallsymsMapped 全局实例，导出为 /proc/kallsyms 文件。
5. SeqFileContent trait（file.rs）：泛化 SeqFile 的内容返回类型，支持 Vec<u8>、String、&'static str、&'static [u8]、Cow<'static, [u8]>，避免不必要的内存分配。

实现逻辑

整体设计合理：构建时从 ELF 提取符号并注入 .kallsyms 段，运行时从该段读取并通过 procfs 暴露。LazyInit 确保符号表只解析一次，dump_all_symbols() 预计算所有符号的格式化字符串存入静态 ALL_SYMS，后续读取直接返回引用，无额外开销。

kallsyms post-build 命令在 uImage 生成之前注入，保证 rust-objcopy 修改 ELF 后 mkimage 能正确打包。

本地验证结果

• cargo fmt --check（scripts/axbuild）：✅ 通过
• cargo clippy -p starry-kernel -- -D warnings：✅ 通过（新 push 已修复 let_and_return）
• cargo clippy --manifest-path scripts/axbuild/Cargo.toml -- -D warnings：✅ 通过
• cargo test -- starry::build::tests（15 个测试）：✅ 全部通过
• patch_starry_cargo_config_runs_kallsyms_before_uimage_generation：✅ 验证 post-build 命令顺序正确

CI 状态

CI workflow run #3351（旧 head 6d961ad4e）中 "Run clippy / run_container" 因 clippy::let_and_return 失败。作者已在新 push（93c69b056）中修复此问题。本地验证新 head 的 clippy 通过。其他 CI 任务在 clippy 失败导致取消前已通过。

非阻塞性建议

1. starry-kallsyms.sh 第 84 行 awk '$3 != "$x"' 是无效过滤（对比字面量），建议移除或改为实际去重逻辑。
2. read_kallsyms() 中的 .expect() 在 kallsyms 数据缺失时会导致内核 panic，建议改为 graceful degradation。

Powered by mimo-v2.5-pro

[mai-team-app]

PR #837 审核：内核符号导出（kallsyms）支持

变更概述

本 PR 为 StarryOS 引入 /proc/kallsyms 支持，涉及 7 个文件、243 行新增代码：

1. 链接脚本（ext_linker.ld）：在 .data 段后新增 .kallsyms 段，预留 8MB 空间，由 rust-objcopy --update-section 写入实际数据。
2. 构建脚本（starry-kallsyms.sh）：新增 post-build 步骤，使用 rust-nm 提取内核符号并用 gen_ksym 生成二进制符号表。
3. 构建集成（build.rs）：在 patch_starry_cargo_config 中注入 kallsyms post-build 命令，保证在 uImage 生成之前执行。
4. 内核初始化（proc.rs）：读取 .kallsyms 段数据，初始化 KallsymsMapped 全局实例，导出为 /proc/kallsyms。
5. SeqFileContent trait（file.rs）：泛化 SeqFile 返回类型，支持 Vec<u8>、String、&'static str、&'static [u8]、Cow<'static, [u8]>，避免不必要的堆分配。

实现逻辑

整体设计合理：构建时从 ELF 提取符号注入 .kallsyms 段，运行时从该段读取并暴露。LazyInit 确保只解析一次，dump_all_symbols() 预计算格式化字符串存入静态 ALL_SYMS，后续读取直接返回引用。kallsyms 命令在 uImage 之前注入，顺序正确。

SeqFileContent trait 为泛型闭包提供了零拷贝返回路径，&'static str 实现直接返回 Cow::Borrowed，对 kallsyms 这种大文本非常合适。

本地验证结果

• cargo fmt --check：✅ 通过
• cargo clippy --manifest-path scripts/axbuild/Cargo.toml --all-features -- -D warnings：✅ 通过
• cargo test --manifest-path scripts/axbuild/Cargo.toml --all-features（377 个测试）：✅ 全部通过
• patch_starry_cargo_config_runs_kallsyms_before_uimage_generation：✅ 验证 post-build 命令顺序正确
• cargo clippy --manifest-path os/StarryOS/kernel/Cargo.toml --all-features：❌ 失败，但是 pre-existing ax-hal 中 __PERCPU_IN_KCOV_TRACE 未定义的错误，与本 PR 无关（PR 未修改 axhal 模块）。

CI 状态

CI workflow run #3351 中旧 head（6d961ad4e）的 "Run clippy" 因 clippy::let_and_return 失败。作者已在新 push（93c69b056）中修复。由于旧 clippy 失败，后续任务均被标记为 skipped。本地验证新 head 的 clippy 通过。

既有审核意见

• Copilot 和之前 mai-bot 审核已提出 awk '$3 != "$x"'（第 84 行）为无效过滤（字面比较），以及 read_kallsyms() 中 .expect() 可能在数据损坏时 panic 的建议。这些均为非阻塞性建议，不影响功能正确性。

已知限制

• 链接脚本预留固定 8MB 空间；对于符号表超大的内核可能不够，但 rust-objcopy --update-section 仅写入实际数据大小。
• /proc/kallsyms 无权限限制，与 Linux kptr_restrict 机制不同，但对开发/调试场景足够。

无阻塞性问题，批准合并。

Powered by mimo-v2.5-pro

[mai-team-app]

PR #837 审核：内核符号导出（kallsyms）支持

变更概述

本 PR 为 StarryOS 引入 /proc/kallsyms 支持，涉及 15 个文件、259 行新增代码：

1. 链接脚本（ext_linker.ld）：在 .data 段后新增 .kallsyms 段，预留 8MB 空间，构建后由 rust-objcopy --update-section 写入实际符号数据。
2. 构建脚本（starry-kallsyms.sh）：新增 post-build 步骤，使用 rust-nm 提取内核符号，通过 gen_ksym 生成二进制符号表，再用 rust-objcopy 注入 ELF。
3. 构建集成（build.rs）：在 patch_starry_cargo_config 中注入 kallsyms post-build 命令，保证在 uImage 生成之前执行（顺序正确，已有测试覆盖）。
4. 内核初始化（proc.rs）：读取 .kallsyms 段数据，初始化 KallsymsMapped 全局实例，导出为 /proc/kallsyms（权限 0444）。
5. SeqFileContent trait（file.rs）：泛化 SeqFile 返回类型，支持 Vec<u8>、String、&'static str、&'static [u8]，避免不必要的堆分配，设计合理。
6. SpecialFsFile::append 修复：正确返回 write_at 的实际写入字节数，修复了原有的静默丢字节数 bug。

实现逻辑

整体设计合理：构建时从 ELF 提取符号注入 .kallsyms 段，运行时从该段读取并暴露。LazyInit 确保只解析一次，dump_all_symbols() 预计算格式化字符串存入静态 ALL_SYMS，后续读取返回 &'static str，通过 SimpleFileContent trait 直接返回 Cow::Borrowed，对大文本零拷贝，非常合适。

kallsyms post-build 命令在 uImage 之前注入，顺序正确，patch_starry_cargo_config_runs_kallsyms_before_uimage_generation 测试已覆盖。

阻塞性问题

1. 四个架构的 QEMU 配置 fail_regex 被清空

提交 0c88a50e9 以 "avoid qemu panic matcher for kallsyms output" 为由，将全部四个 QEMU 配置的 fail_regex 从 ["(?i)\\bpanic(?:ked)?\\b"] 改为 []。这是严重的 CI 退化：

• kallsyms 数据存储在内核内存中，通过 /proc/kallsyms 文件读取，不会输出到 QEMU 串口。fail_regex 匹配的是 QEMU 串口输出，与 kallsyms 文件内容无关。
• 移除 panic 匹配后，所有架构的 QEMU 测试将无法检测到内核 panic，可能掩盖真实的内核崩溃 bug（包括本 PR 引入的 .expect() 潜在 panic）。
• 如果移除是因为构建后的内核确实会 panic，那说明 kallsyms 功能本身有问题，应当修复根因而非屏蔽检测。
• 请恢复 fail_regex，或者在 PR 描述中提供具体证据说明哪个 "kallsyms output" 会触发 panic 正则误匹配。

本地验证结果

• cargo fmt --check（scripts/axbuild）：✅ 通过
• cargo clippy --manifest-path scripts/axbuild/Cargo.toml --all-features -- -D warnings：✅ 通过
• cargo test --manifest-path scripts/axbuild/Cargo.toml -- starry::build::tests（15 个测试）：✅ 全部通过
• patch_starry_cargo_config_runs_kallsyms_before_uimage_generation：✅ 验证 post-build 命令顺序正确

CI 状态

当前 head（0c88a50e）的 CI check runs 全部为 skipped 状态（因之前 clippy 失败导致跳级），CI 未实际运行本 head 的任何测试。无法以 CI 结果作为质量参考。

重复/重叠分析

• base 分支（origin/dev）上无 kallsyms 相关功能（git grep 确认），本 PR 是该功能的首个实现。
• PR #849（LKM loader）和 PR #851（LKM loader 另一实现）均声明依赖本 PR 的 kallsyms 功能进行符号解析。无功能重复。
• PR #853（/proc/self/statm, /proc/loadavg）修改同一 proc.rs 文件，有潜在的合并冲突风险（partial-overlap），但变更区域不同（kallsyms 在 builder 末尾，statm/loadavg 在 per-pid 区域），冲突范围小。

非阻塞性建议

1. starry-kallsyms.sh 第 84 行 awk '$3 != "$x"' 是无效过滤——awk 将 $x 当作字面字符串比较，恒为真。建议移除或改为 awk '!seen[$3]++' 去重。
2. read_kallsyms() 中的 .expect() 在 kallsyms 数据缺失或损坏时会导致内核 panic。建议改为 graceful degradation：记录错误日志并跳过 /proc/kallsyms 注册，确保系统仍可正常启动。
3. 本 PR 混入了不相关的变更：ostool 版本升级（0.18→0.19）、disable_someboot_build_config 字段添加、build.rs/test.rs 结构体字段重排序。建议将这类构建系统更新拆分为独立 PR，降低审查复杂度和回归风险。

Powered by glm-5.1

[mai-team-app]

PR #837 审核：内核符号导出（kallsyms）支持

变更概述

本 PR 为 StarryOS 引入 /proc/kallsyms 支持，涉及 15 个文件、266 行新增代码：

1. 链接脚本（ext_linker.ld）：在 .data 段后新增 .kallsyms 段，预留 8MB 空间，构建后由 rust-objcopy --update-section 写入实际数据。
2. 构建脚本（starry-kallsyms.sh）：新增 post-build 步骤，使用 rust-nm 提取内核符号，通过 gen_ksym 生成二进制符号表，再用 rust-objcopy 注入 ELF。
3. 构建集成（build.rs）：在 patch_starry_cargo_config 中注入 kallsyms post-build 命令，保证在 uImage 生成之前执行（顺序正确，新增测试覆盖）。
4. 内核初始化（proc.rs）：读取 .kallsyms 段数据，使用 KallsymsMapped::check_total_bytes 确定实际大小，裁剪后 leak 为 &'static [u8]，注册到 global_add_memory，初始化 KallsymsMapped 全局实例，通过 SeqObject + SpecialFsFile::new_regular_with_perm 导出为 /proc/kallsyms（权限 0444）。
5. SimpleFileContent trait（file.rs）：泛化 SimpleFile 闭包返回类型，支持 Vec<u8>、String、&'static str、&'static [u8]，避免不必要的堆分配。write_all 默认返回 BadFileDescriptor。
6. SpecialFsFile::append 修复：正确返回 write_at 的实际写入字节数，修复了原有的静默丢字节数 bug。
7. SimpleFileContent 重构：将 Into<Vec<u8>> 约束替换为 SimpleFileContent trait，&'static str 直接返回 Cow::Borrowed，对 kallsyms 大文本零拷贝。

实现逻辑

整体设计合理：构建时从 ELF 提取符号注入 .kallsyms 段，运行时从该段读取并暴露。最新提交（4e497ea05）改进了 kallsyms 数据处理——使用 check_total_bytes 精确确定数据大小而非使用整个 8MB 段，并通过 global_add_memory 将段内存注册到内核分配器实现回收。LazyInit 确保只解析一次，dump_all_symbols() 预计算格式化字符串存入静态 ALL_SYMS，后续读取返回 &'static str。

kallsyms post-build 命令在 uImage 之前注入，顺序正确，新增测试 patch_starry_cargo_config_runs_kallsyms_before_uimage_generation 已覆盖。

本地验证结果

• cargo fmt --check（scripts/axbuild）：✅ 通过
• cargo clippy --manifest-path scripts/axbuild/Cargo.toml --all-features -- -D warnings：✅ 通过
• cargo test --manifest-path scripts/axbuild/Cargo.toml -- starry::build::tests（15 个测试）：✅ 全部通过

CI 状态

当前 head（4e497ea05）的 CI 尚未运行（之前 head 的 clippy 失败导致后续 job 跳级）。无法以 CI 结果作为质量参考。

阻塞性问题

1. 四个架构的 QEMU 配置 fail_regex 被清空（提交 0ae398d6e）

全部四个 QEMU 配置（x86_64、aarch64、riscv64、loongarch64）的 fail_regex 从 ["(?i)\\bpanic(?:ked)?\\b"] 改为 []。这是严重的 CI 退化：

• kallsyms 数据存储在内核内存中，通过 /proc/kallsyms 文件读取，不会输出到 QEMU 串口。fail_regex 匹配的是 QEMU 串口输出，与 kallsyms 文件内容无关。
• 移除 panic 匹配后，所有架构的 QEMU 测试将无法检测到内核 panic，可能掩盖真实的内核崩溃 bug（包括本 PR 引入的 .expect() 潜在 panic）。
• 如果移除是因为构建后的内核确实会 panic，那说明 kallsyms 功能本身有问题，应当修复根因而非屏蔽检测。
• 请恢复 fail_regex，或者在 PR 描述/评论中提供具体证据说明哪个 "kallsyms output" 会触发 panic 正则误匹配。

重复/重叠分析

• base 分支（origin/dev）上无 kallsyms 相关功能（git grep 确认），本 PR 是该功能的首个实现。
• 已检查的开放 PR 中无 kallsyms 相关 PR。eBPF PR #888 使用 kallsyms 进行符号解析但声明依赖本 PR，不属于功能重复。

非阻塞性建议

1. starry-kallsyms.sh 第 84 行 awk '$3 != "$x"' 中 $x 在 awk 单引号内被当作字面字符串，该条件几乎恒为真，等于无过滤。如果目的是去重，建议改为 awk '!seen[$3]++'；如果不需要额外过滤，可直接移除此行管道。
2. read_kallsyms() 中存在多处 .expect() / .unwrap()，在 kallsyms 数据缺失或损坏时会导致内核 panic。建议改为 graceful degradation：记录错误日志并跳过 /proc/kallsyms 注册，确保系统仍可正常启动。
3. starry-kallsyms.sh 中 auto_install_enabled 默认为启用（:-1），可能在 CI/开发者环境中意外触发 cargo install。建议默认禁用或仅在明确 opt-in 时安装。
4. 本 PR 混入了不相关的变更：ostool 版本升级（0.18→0.19）、disable_someboot_build_config 字段添加、build.rs/test.rs 结构体字段重排序。建议将构建系统更新拆分为独立 PR。

Powered by mai-team

Powered by glm-5.1

[mai-team-app]

🚫 阻塞性问题：fail_regex 被清空后，CI 将无法检测 x86_64 QEMU 测试中的内核 panic。提交消息说 "avoid qemu panic matcher for kallsyms output"，但 kallsyms 数据存储在内核内存中（/proc/kallsyms 文件），不会输出到 QEMU 串口，不应触发 panic 正则匹配。如果确实存在误匹配，请在 PR 评论中提供具体证据（如 QEMU 串口日志中包含 "panic" 的 kallsyms 相关输出行）。否则请恢复原 fail_regex = ["(?i)\\\\bpanic(?:ked)?\\\\b"]。

[mai-team-app]

🚫 同上，aarch64 配置的 panic 检测也被移除。所有四个架构的 fail_regex 均被清空，这是一项全架构范围的 CI 退化。

[mai-team-app]

💡 非阻塞建议：auto_install_enabled 默认为启用（:-1），可能在 CI/开发者环境中意外触发 cargo install ksym 或 cargo install cargo-binutils。建议默认禁用（改为 :-0），仅在 AXBUILD_STARRY_KALLSYMS_AUTO_INSTALL=1 显式启用时安装。

[Godones]

@ZR233 这似乎不是回收带来的问题？

[ZR233]

@ZR233 这似乎不是回收带来的问题？

但确实引起 ci 出现问题，需要查查哪里引起的

[mai-team-app]

PR #837 审核：内核符号导出（kallsyms）支持

变更概述

本 PR 为 StarryOS 引入 /proc/kallsyms 支持，涉及 11 个文件、257 行新增代码：

1. 链接脚本（ext_linker.ld）：在 .data 段后新增 .kallsyms 段，预留 8MB 空间，构建后由 rust-objcopy --update-section 写入实际符号数据。
2. 构建脚本（starry-kallsyms.sh）：新增 post-build 步骤，使用 rust-nm 提取内核符号，过滤后通过 gen_ksym 生成二进制符号表，再用 rust-objcopy 注入 ELF。
3. 构建集成（build.rs）：在 patch_starry_cargo_config 中注入 kallsyms post-build 命令，保证在 uImage 生成之前执行。
4. 内核初始化（proc.rs）：读取 .kallsyms 段数据，使用 check_total_bytes 确定实际大小，初始化 KallsymsMapped 全局实例，导出为 /proc/kallsyms（权限 0444）。
5. SimpleFileContent trait（file.rs）：泛化 SimpleFile 闭包返回类型，支持 Vec<u8>、String、&'static str、&'static [u8]，避免不必要的堆分配。
6. SpecialFsFile::append 修复：正确返回 write_at 的实际写入字节数，修复了原有的静默丢字节数 bug。

实现逻辑

整体设计合理：构建时从 ELF 提取符号注入 .kallsyms 段，运行时从该段读取并暴露。LazyInit 确保只解析一次，dump_all_symbols() 预计算格式化字符串存入静态 ALL_SYMS，后续读取返回 &'static str 通过 SimpleFileContent trait 直接返回 Cow::Borrowed，对大文本零拷贝。

SimpleFileContent trait 设计干净，&'static str 实现直接返回 Cow::Borrowed，write_all 默认返回 BadFileDescriptor 语义正确。

关于之前审核中反复提到的 awk '$3 != "$x"' 过滤：经重新分析，$x 是 AArch64 架构的 mapping symbol（标记 ARM/Thumb 边界），这个过滤是有效的，不是无效代码。在 x86_64/RISC-V 上无匹配符号，无害过滤。

本地验证结果

• cargo fmt --check（scripts/axbuild）：✅ 通过
• cargo clippy --manifest-path scripts/axbuild/Cargo.toml --all-features -- -D warnings：✅ 通过
• cargo test --manifest-path scripts/axbuild/Cargo.toml -- starry::build::tests：❌ 编译失败（详见阻塞性问题）

CI 状态

当前 head（ea9e1bee）的 CI 状态未知。之前多次 head 因 clippy 或 test 失败被标记为 blocked。

重复/重叠分析

• base 分支（origin/dev）上无 kallsyms 相关功能（git grep 确认），本 PR 是该功能的首个实现。
• 之前审核指出的 fail_regex 被清空问题，在当前 head 已恢复，QEMU 配置文件与 dev 分支完全一致。

阻塞性问题

1. 新增测试 patch_starry_cargo_config_runs_kallsyms_before_uimage_generation 编译失败

starry/build.rs:675 调用 StarryBuildInfo::build_cargo_args(&request.target, false, &[]) 传入了 3 个参数，但该函数签名只接受 2 个参数（target: &str, extra_rustflags: &[String]）。这导致整个 axbuild test 无法编译。

同一文件中其他测试（line 518、568、623）均正确使用 2 参数版本。修复方式：移除多余的 false 参数，改为 StarryBuildInfo::build_cargo_args(&request.target, &[])。

非阻塞性建议

1. read_kallsyms() 中的 .expect() 在 kallsyms 数据缺失或损坏时会导致内核 panic。建议改为 graceful degradation：记录错误日志并跳过 /proc/kallsyms 注册。
2. 链接脚本预留固定 8MB 空间，代码中已有 TODO 注释。建议后续实现空间回收或动态调整。

Powered by mai-team

Powered by glm-5.1

[Godones]

@ZR233 这似乎不是回收带来的问题？

但确实引起 ci 出现问题，需要查查哪里引起的

应该是内存压力造成的问题，我统一调整了util-linux的qemu启动参数。新的测试错误似乎来自多核测试，与该PR引入的内容无关。

[mai-team-app]

PR #837 审核：内核符号导出（kallsyms）支持

变更概述

本 PR 为 StarryOS 引入 /proc/kallsyms 支持，涉及 14 个文件、262 行新增代码：

1. 链接脚本（ext_linker.ld）：在 .data 段后新增 .kallsyms 段，预留 8MB 空间，构建后由 rust-objcopy --update-section 写入实际符号数据。
2. 构建脚本（starry-kallsyms.sh）：新增 post-build 步骤，使用 rust-nm 提取内核符号，通过 gen_ksym 生成二进制符号表，再用 rust-objcopy 注入 ELF。
3. 构建集成（build.rs）：在 patch_starry_cargo_config 中注入 kallsyms post-build 命令，保证在 uImage 生成之前执行（顺序正确，有测试覆盖）。
4. 内核初始化（proc.rs）：读取 .kallsyms 段数据，使用 KallsymsMapped::check_total_bytes 确定实际大小，初始化全局实例，通过 SeqObject + SpecialFsFile::new_regular_with_perm 导出为 /proc/kallsyms（权限 0444）。
5. SimpleFileContent trait（file.rs）：泛化 SimpleFile 闭包返回类型，支持 Vec<u8>、String、&'static str、&'static [u8]，避免不必要的堆分配。
6. SpecialFsFile::append 修复：正确返回 write_at 的实际写入字节数，修复了原有的静默丢字节数 bug。
7. util-linux 测试内存配置：4 个架构的 QEMU 配置增加 -m 512M，解决 kallsyms 8MB 预留段导致的内存不足问题。

实现逻辑

整体设计合理：构建时从 ELF 提取符号注入 .kallsyms 段，运行时从该段读取并暴露。LazyInit 确保只解析一次，dump_all_symbols() 预计算格式化字符串存入静态 ALL_SYMS，后续读取返回 &'static str 通过 SimpleFileContent trait 直接返回 Cow::Borrowed，对大文本零拷贝。kallsyms post-build 命令在 uImage 之前注入，顺序正确。

既有审核意见处理

• fail_regex 清空问题：✅ 已解决。当前 head 不再修改 QEMU 配置文件，四个架构的 fail_regex 均保持原值 [(?i)\bpanic(?:ked)?\b]。

阻塞性问题

1. 新增测试 patch_starry_cargo_config_runs_kallsyms_before_uimage_generation 编译失败

starry/build.rs 第 675 行调用 StarryBuildInfo::build_cargo_args(&request.target, false, &[]) 传入了 3 个参数，但 build_cargo_args 函数签名是 fn build_cargo_args(target: &str, extra_rustflags: &[String]) -> Vec<String>（仅 2 个参数）。编译错误：

error[E0061]: this function takes 2 arguments but 3 arguments were supplied
   --> scripts/axbuild/src/starry/build.rs:675:13

应将调用改为 StarryBuildInfo::build_cargo_args(&request.target, &[])，移除多余的 false 参数。

本地验证结果

• cargo fmt --check（scripts/axbuild）：✅ 通过
• cargo clippy --manifest-path scripts/axbuild/Cargo.toml --all-features -- -D warnings：✅ 通过（二进制编译无问题）
• cargo test --manifest-path scripts/axbuild/Cargo.toml -- starry::build::tests：❌ 失败，新增测试编译错误（见上）

CI 状态

当前 head（5748676fa）无任何 CI check run。无法以 CI 结果作为质量参考。

重复/重叠分析

• base 分支（origin/dev）上无 kallsyms 相关功能（git grep 确认），本 PR 是该功能的首个实现。
• 已检查的开放 PR 中：#847（kprobe）、#849/#851（LKM loader）、#850（eBPF）、#886（用户态 eBPF）均声明依赖本 PR 的 kallsyms 功能进行符号解析，属于下游依赖而非功能重复。
• PR #853（/proc/self/statm, /proc/loadavg）修改同一 proc.rs 文件，有潜在的合并冲突风险（partial-overlap），但变更区域不同，冲突范围小。

非阻塞性建议

1. starry-kallsyms.sh 第 84 行 awk '$3 != "$x"' 中 $x 在 awk 单引号内被当作字面字符串，该条件几乎恒为真，等于无过滤。如果目的是去重，建议改为 awk '!seen[$3]++'；如果不需要额外过滤，可直接移除此行管道。
2. read_kallsyms() 中存在多处 .expect()（第 62、72 行），在 kallsyms 数据缺失或损坏时会导致内核 panic。建议改为 graceful degradation：记录错误日志并跳过 /proc/kallsyms 注册，确保系统仍可正常启动。
3. starry-kallsyms.sh 中 auto_install_enabled 默认为启用（:-1），可能在 CI/开发者环境中意外触发 cargo install。建议默认禁用或仅在明确 opt-in 时安装。

Powered by mai-team

Powered by glm-5.1

[Godones]

@ZR233 现在应该没有问题了，请帮忙合并

[mai-team-app]

PR #837 审核：内核符号导出（kallsyms）支持

变更概述

本 PR 为 StarryOS 引入 /proc/kallsyms 支持，涉及 14 个文件、262 行新增代码：

1. 链接脚本（ext_linker.ld）：在 .data 段后新增 .kallsyms 段，预留 8MB 空间，构建后由 rust-objcopy --update-section 写入实际符号数据。
2. 构建脚本（starry-kallsyms.sh）：新增 post-build 步骤，使用 rust-nm 提取内核符号，通过 gen_ksym 生成二进制符号表，再用 rust-objcopy 注入 ELF。
3. 构建集成（build.rs）：在 patch_starry_cargo_config 中注入 kallsyms post-build 命令，保证在 uImage 生成之前执行（顺序正确）。
4. 内核初始化（proc.rs）：读取 .kallsyms 段数据，使用 check_total_bytes 精确确定数据大小，初始化 KallsymsMapped 全局实例，通过 SeqObject + SpecialFsFile::new_regular_with_perm 导出为 /proc/kallsyms（权限 0444）。
5. SimpleFileContent trait（file.rs）：泛化 SimpleFile 闭包返回类型，支持 Vec<u8>、String、&'static str、&'static [u8]，避免不必要的堆分配。
6. SpecialFsFile::append 修复：正确返回 write_at 的实际写入字节数，修复了原有的静默丢字节数 bug。
7. QEMU 内存配置：四个架构的 util-linux 测试 QEMU 配置增加 -m 512M 参数，适配 kallsyms 占用内存后的需求。
8. bin 字段重排（build.rs/test.rs）：将 bin 字段移至 to_bin 之后，与 Cargo config 序列化顺序一致。

实现逻辑

整体设计合理：构建时从 ELF 提取符号注入 .kallsyms 段，运行时从该段读取并暴露。check_total_bytes 精确确定数据大小（非使用整个 8MB），LazyInit 确保只解析一次，dump_all_symbols() 预计算格式化字符串存入静态 ALL_SYMS，后续读取返回 &'static str 通过 SimpleFileContent trait 直接返回 Cow::Borrowed，对大文本零拷贝。kallsyms post-build 命令在 uImage 之前注入，顺序正确，新增测试已覆盖。

既有审核意见

• 之前的 fail_regex 清空问题已解决：当前 head 与 dev 分支的 os/StarryOS/configs/qemu/qemu-*.toml 完全一致，fail_regex 未被修改。
• ZR233 已在 review #4356498826 中批准 commit defea9e7e。当前 head（ac6e0648）在此基础上新增了 util-linux QEMU 内存配置修复。
• awk '$3 != "$x"' 无效过滤、read_kallsyms() 中 .expect() 可能导致内核 panic 等非阻塞建议已在多轮审核中提出。

本地验证结果

• cargo fmt --check（scripts/axbuild）：✅ 通过
• cargo clippy --manifest-path scripts/axbuild/Cargo.toml --all-features -- -D warnings：✅ 通过
• cargo test --manifest-path scripts/axbuild/Cargo.toml -- starry::build::tests：❌ 编译失败

阻塞性问题

1. 新增测试 patch_starry_cargo_config_runs_kallsyms_before_uimage_generation 编译失败

scripts/axbuild/src/starry/build.rs 第 731 行调用 StarryBuildInfo::build_cargo_args(&request.target, false, &[]) 使用了 3 个参数，但 build_cargo_args 函数签名只有 2 个参数 (target: &str, extra_rustflags: &[String])。该测试是本 PR 新增的，从未通过编译。

编译错误：

error[E0061]: this function takes 2 arguments but 3 arguments were supplied
   --> scripts/axbuild/src/starry/build.rs:731:13
    |
731 |             StarryBuildInfo::build_cargo_args(&request.target, false, &[]),
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                  ----- unexpected argument #2 of type `bool`

修复方法：移除多余的 false 参数，改为 StarryBuildInfo::build_cargo_args(&request.target, &[])。

重复/重叠分析

• base 分支（origin/dev）上无 kallsyms 相关功能（git grep 确认），本 PR 是该功能的首个实现。
• 相关开放 PR（#847 kprobe、#849/#851 LKM loader、#888 eBPF 等）均声明依赖本 PR 的 kallsyms 功能，属于下游依赖而非功能重复。

非阻塞性建议

1. starry-kallsyms.sh 第 84 行 awk '$3 != "$x"' 中 $x 在 awk 单引号内被当作字面字符串，该条件几乎恒为真，等于无过滤。建议移除或改为 awk '!seen[$3]++' 去重。
2. read_kallsyms() 中的 expect() 调用在 kallsyms 数据缺失或损坏时会导致内核 panic。建议改为 graceful degradation：记录错误日志并跳过 /proc/kallsyms 注册。
3. starry-kallsyms.sh 中 auto_install_enabled 默认为启用（:-1），可能在 CI/开发者环境中意外触发 cargo install。建议默认禁用。

Powered by mai-team

Powered by glm-5.1

[mai-team-app]

⚠️ 阻塞性问题：build_cargo_args 函数签名只有 2 个参数 (target: &str, extra_rustflags: &[String])，但这里传入了 3 个参数 (target, false, &[])。false 是多余的参数，导致该测试无法通过编译。

修复方法：移除 false，改为：

StarryBuildInfo::build_cargo_args(&request.target, &[])

[mai-team-app]

💡 非阻塞建议：awk '$3 != "$x"' 中 $x 在 awk 单引号内被当作字面字符串，该条件几乎恒为真，等于无过滤。如果目的是去重，建议改为 awk '!seen[$3]++'；如果不需要额外过滤，可直接移除此行管道。

[mai-team-app]

💡 非阻塞建议：此处 expect("Invalid kallsyms format") 在 kallsyms 数据格式无效时会导致内核 panic。建议改为 graceful degradation：记录 warn! 日志并让 read_kallsyms() 返回 Option<KallsymsMapped>，在调用方跳过 /proc/kallsyms 注册。

done