Repository navigation
[dlmodule][utest] add QEMU regression coverage - #11989
usualtreee wants to merge 2 commits into
Conversation
|
👋 感谢您对 RT-Thread 的贡献!Thank you for your contribution to RT-Thread! 为确保代码符合 RT-Thread 的编码规范,请在你的仓库中执行以下步骤运行代码格式化工作流(如果格式化CI运行失败)。 🛠 操作步骤 | Steps
完成后,提交将自动更新至 如有问题欢迎联系我们,再次感谢您的贡献!💐 |
📌 Code Review Assignment🏷️ Tag: componentsReviewers: @Maihuanyi Changed Files (Click to expand)
🏷️ Tag: components_libcReviewers: @GorrayLi @mysterywolf Changed Files (Click to expand)
🏷️ Tag: kernelReviewers: @GorrayLi @ReviewSun @hamburger-os @lianux-mm @wdfk-prog @xu18838022837 Changed Files (Click to expand)
🏷️ Tag: workflowReviewers: @Rbb666 @kurisaW @supperthomas Changed Files (Click to expand)
📊 Current Review Status (Last Updated: 2026-11-06 10:59 CST)
📝 Review Instructions
|
Rbb666
left a comment
There was a problem hiding this comment.
复核提交 0c03a843b2576c23e911bd540ce75c3f919d5660。已核对 A9 专项 CI:运行器 8 项自测通过,10 个模块测试单元实际执行,并输出 DLMODULE_QEMU_PASS cases=10。
[P2] 请将新增测试选项限制为 32 位 ARM。
utest/Kconfig 第 2–4 行 的 ARCH_ARM_CORTEX_A && !RT_USING_SMART 不能排除 AArch64。例如 i.MX91 同时选择 ARCH_ARM_CORTEX_A55、ARCH_ARMV8 和 ARCH_CPU_64BIT,其默认标准内核配置允许满足当前依赖。
但本用例的生成器固定使用 -marm -mcpu=arm926ej-s,并验证 ELF32/EM_ARM;C 用例也用 uint32_t 保存指针,无法作为 AArch64 用例运行。本轮 Kconfig 验证中,i.MX91 可以同时得到 ARCH_CPU_64BIT=y 和 RT_UTEST_DLMODULE=y,说明新增选项的架构限制确实不足。
请至少增加 depends on !ARCH_CPU_64BIT,在提示或帮助中明确 32 位 ARM,并验证 A9 仍可启用、i.MX91 的 64 位配置不能启用。此处已验证配置可达性,未声称完成 i.MX91 固件构建。
其余改动围绕同一项模块加载回归测试,标题、说明和提交组织清晰。请补齐该配置限制后再合并。
|
dlmodule 这条 CI 跑完自定义脚本就 |
|
BernardXiong
left a comment
There was a problem hiding this comment.
结论:方向正确,runner 的检查比较扎实;有两处需要调整。
1. [P2] 依赖没有排除 64 位 Cortex-A
ARCH_ARM_CORTEX_A 不区分 32/64 位:例如 i.MX91 的 Cortex-A55 会同时选中 ARCH_ARM_CORTEX_A、ARCH_ARMV8、ARCH_CPU_64BIT。而 build_fixtures.py#L68 固定使用 -marm -mcpu=arm926ej-s,并断言 ELF32/EM_ARM;测试代码也用 uint32_t 保存指针,无法在 AArch64 上运行。
建议增加 depends on !ARCH_CPU_64BIT,并在 help 中明确“32 位 ARM GCC”。
2. [P2] exit 0 提前结束,绕过官方 monitor
自定义 runner 成功后直接 exit 0,同时 monitor step 对该配置被排除。虽然 runner 当前实现较严格,但这里丢掉了统一 monitor 的失败汇总路径,后续调整 runner 时容易变成假绿。建议去掉 exit 0,让 runner 的退出码自然作为 step 结果。
3. [建议]
- dlmodule_tc.c#L290
test_init在/dlmutest已存在时直接失败;建议接受EEXIST或先清理,避免上次异常退出后重跑失败(新的多轮模式也会受影响)。 - build_fixtures.py#L35-L54 对
st_shndx和对齐的硬断言依赖具体 GCC 行为;当前是 opt-in 的 CI 用例可以接受,但换编译器版本会以构建失败形式暴露,建议在帮助中说明。 src/defunct.c增加#include <dlmodule.h>本身是对的(后面调用了dlmodule_destroy),但与本次测试无关,建议拆成独立提交。
tools/ci/test_run_dlmodule_qemu.py 的 8 项自测、10 个单元全量校验和 DLMODULE_QEMU_PASS cases=10 的设计是好的。
拉取/合并请求描述:(PR description)
[
为什么提交这份PR (why to submit this PR)
这是已合并的 #11915 的测试补充。将动态模块加载、符号解析和卸载回归用例整理为 utest,并接入 qemu-vexpress-a9 CI,持续看护 COMMON、多个 NOBITS 节、跨节重定位、非零节地址和调试重定位等场景。
你的解决方案是什么 (what is your solution)
components.libc.posix.libdl.regression,包含 10 个测试单元,覆盖 ET_REL、ET_DYN、内核符号导入、符号导出及重复加载卸载。src/defunct.c仅补充模块接口声明,以满足启用RT_USING_MODULE后的--strict编译。本地验证:使用 GCC 14.2.1、QEMU 10.2.1,按 CI 配置严格构建通过;10 个单元连续运行两轮均通过。8 项运行器自测、断言失败对照、默认配置构建、clang-format 22.1.8、Python 语法、YAML 配置检查和
git diff --check均通过。GitHub Actions 仍需在提交后验证。请提供验证的bsp和config (provide the config and bsp)
BSP: bsp/qemu-vexpress-a9
.config: CONFIG_RT_USING_UTESTCASES、CONFIG_RT_CONSOLEBUF_SIZE=1024、CONFIG_RT_NAME_MAX=24、CONFIG_RT_USING_CI_ACTION、CONFIG_RT_USING_MODULE、CONFIG_RT_USING_DFS、CONFIG_RT_USING_POSIX_FS、CONFIG_RT_UTEST_DLMODULE、CONFIG_UTEST_THR_STACK_SIZE=8192
action: 待创建 PR 后运行 GitHub Actions;当前仅完成本地验证。
]
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
代码质量 Code Quality:
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
#if 0代码,不包含已经被注释了的代码 All redundant code is removed and cleaned up