Repository navigation
[dlmodule][utest] add QEMU regression coverage - #11989
Conversation
|
👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread! 为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流（如果格式化CI运行失败）。 🛠 操作步骤 | Steps
完成后，提交将自动更新至 如有问题欢迎联系我们，再次感谢您的贡献！💐 |
github-actions
Bot
added
Kernel
📌 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-12 15:59 CST)
📝 Review Instructions
|
Rbb666
left a comment
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
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 的设计是好的。
BernardXiong
left a comment
BernardXiong
left a comment
There was a problem hiding this comment.
复核最新 head 129b2407：上一轮提出的三项已处理——RT_UTEST_DLMODULE 增加 !ARCH_CPU_64BIT、移除自定义 runner 后的 exit 0 让统一 monitor 生效、test_init 接受已存在的测试目录。
当前没有可用的 CI 结果：该 head 的 utest_auto_run（37 个 job）、RT-Thread BSP Static Build Check（33 个 job）和 pkgs_test 都在 2026-11-06T03:19Z 同时变为 cancelled，属于运行层面的整体取消；同一时间另一个 PR 的 utest/BSP/pkgs run 也在同一秒被取消。因此这些红色状态既不是代码失败，也不是新 head 的测试结论。
建议重新触发一次 workflow，确认 dlmodule 专项 job 与统一 monitor 都实际跑通后再合入。
BernardXiong
left a comment
BernardXiong
left a comment
There was a problem hiding this comment.
结论：可以合入，未发现阻塞问题。
复核 head e28d7b29（包含一次上游 master 合并）：
- 上一轮三项均已落实：
RT_UTEST_DLMODULE增加!ARCH_CPU_64BIT、移除自定义 runner 的exit 0、test_init接受已存在的测试目录。 - 合并上游后
run_dlmodule_qemu.py改为等待[==========] [ utest ] all loops finished，并新增“多轮完成”和“仅首轮完成应失败”的自测，与主线 utest loop 输出一致。 - 实测 A9 dlmodule job 通过：日志包含
DLMODULE_QEMU_PASS cases=10和all loops finished，统一 monitor 正常生效（job）。 - 全量 CI：110 pass / 4 skipping。
|
@usualtreee 帮忙确认下这个运行的警告是否符合预期？ 
|
|
@Rbb666 这两条警告符合预期。它们来自 该提示不会中止加载，两个单元及完整 testcase 均继续执行并通过，并非加载失败或测试跳过。 |
Rbb666
left a comment
Rbb666
left a comment
There was a problem hiding this comment.
已复核当前提交：旧版 !ARCH_CPU_64BIT 条件问题已修复，ELF fixtures、SCons/Kconfig、C 回归用例与 QEMU runner 配套。现有 CI 日志确认 runner 的 10 项自测及 10 个模块用例通过，CLA 通过。三个提交分别为功能、同功能修正和同步 master，建议压缩为一个完整提交。此处未做本地硬件验证。
拉取/合并请求描述：(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