Repository navigation
[components][libc] cplusplus_system_init 补上 .init_array 的构造函数 - #11856
Conversation
|
👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread! 为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流（如果格式化CI运行失败）。 🛠 操作步骤 | Steps
完成后，提交将自动更新至 如有问题欢迎联系我们，再次感谢您的贡献！💐 |
📌 Code Review Assignment🏷️ Tag: bsp_renesasReviewers: @kurisaW Changed Files (Click to expand)
🏷️ Tag: componentsReviewers: @Maihuanyi Changed Files (Click to expand)
🏷️ Tag: components_libcReviewers: @GorrayLi @mysterywolf Changed Files (Click to expand)
🏷️ Tag: workflowReviewers: @Rbb666 @kurisaW @supperthomas Changed Files (Click to expand)
📊 Current Review Status (Last Updated: 2026-10-10 20:34 CST)
📝 Review Instructions
|
|
479b204 to
5dd7cfa
Compare
edf0bd5 to
ca10f96
Compare
Newer GCC emits C++ global constructors into .init_array, which many linker scripts keep outside [__ctors_start__, __ctors_end__), so they never ran. Walk __init_array_start/__init_array_end (weak) as well, skipping entries already covered by the ctors range. Add RT_USING_CPP_CRT_INIT for ports whose startup runtime already runs .init_array, default on for the simulator. With it set, only the .init_array walk is skipped; the ctors range is still walked. Renesas RA/RA_WIRELESS/RZ families select it when C++ is enabled: FSP SystemInit() already walks .init_array, so boards whose linker script only provides __init_array_* would run constructors twice. Boards that fold .init_array into the ctors range (ra6m3-hmi-board, ra8d1, rz) still run them once via RT-Thread. Also source env.sh and restore RTT_EXEC_PATH in ToolsCI project generate and dist steps so scons is on PATH (exit 127) and the ARM toolchain path is not overwritten by env.sh. Fixes RT-Thread#11778
ca10f96 to
ebe02af
Compare
2 participants
拉取/合并请求描述：(PR description)
为什么提交这份PR (why to submit this PR)
Newer GCC puts C++ global constructors into
.init_arrayinstead of the__ctors_start__/__ctors_end__range, socplusplus_system_init()missedthem on ports whose linker script does not merge
.init_arrayinto the ctorsrange. Fixes #11778
你的解决方案是什么 (what is your solution)
Walk
__init_array_start/__init_array_endas well. Both ranges are declaredweak, and each
.init_arrayentry that already lies inside the ctors range isskipped, so full or partial overlap never runs a constructor twice.
Add the Kconfig option
RT_USING_CPP_CRT_INITfor ports whose startupruntime already calls constructors (default on for the simulator, where glibc
runs
.init_arraybeforemain).RT_USING_CPP_CRT_INITmeans the startup code has already run.init_array.With it set,
cplusplus_system_init()skips only the.init_arraywalk; the__ctors_start__/__ctors_end__range is still walked.The Renesas RA/RA_WIRELESS/RZ families select
RT_USING_CPP_CRT_INITwhenC++ is enabled (
bsp/renesas/libraries/Kconfig), because FSPSystemInit()already walks
.init_array:__init_array_*(ra6m4-iot,ra8m1-ek, ra2l1-cpk, ...) run each constructor once, via
SystemInit()..init_arrayinto the ctorsrange, so the FSP walk is empty; they run each constructor once, via
RT-Thread.
请提供验证的bsp和config (provide the config and bsp)
BSP: bsp/simulator
.config: CONFIG_RT_USING_CPLUSPLUS=y, CONFIG_RT_USING_CPP_CRT_INIT=y
A global constructor runs exactly once. A host test also covers the ctors
and init_array range combinations.
BSP: bsp/renesas/ra6m4-iot, bsp/renesas/ra6m3-hmi-board (arm-none-eabi-gcc 14.2.1)
cxx_crt_init.cbuilds without warnings with and without the option, andlinking against each board's
script/fsp.ldgives the expectedconstructor ranges. A host test that models FSP
SystemInit()shows eachconstructor runs once on both board layouts.
action: CI link will be added once checks finish.
当前拉取/合并请求的状态 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