Skip to content

libs: retain strcpy for compiler-generated LTO references - #109

Closed
JiTianYu391 wants to merge 1 commit into
ViudiraTech:developfrom
JiTianYu391:codex/fix-strcpy-lto
Closed

JiTianYu391 wants to merge 1 commit into
ViudiraTech:developfrom
JiTianYu391:codex/fix-strcpy-lto

Conversation

@JiTianYu391

Copy link
Copy Markdown
Contributor

原始 develop 在干净工作树中无法完成 LTO 链接:libs/kobject/kobject.c:605: undefined reference to strcpy。复现命令:关闭 virtio-gpu 后执行 make -j6 C_SOURCES="$(git ls-files '*.c')" UxImage;本轮已保存失败日志 build/kbench/develop-clean-build.log。

GCC 在 LTO 分区中把 strcat 降为 strcpy 调用时,WPA 阶段可能已丢弃原先没有显式引用的定义。只给 strcpy 定义加 __attribute__((used)),保留原拷贝循环和 ABI。参考 U-Boot 同类修复讨论。

验证 原始 develop 本分支
同配置 GCC LTO 链接 strcpy 未定义,失败 成功,生成 UxImage/System.map
strcpy 拷贝算法 原实现 相同

本 PR 不声称性能提升;不采用关闭 LTO 或整体降低优化级别的替代方案。

验证环境:5 vCPU、KVM、2 GiB、每次 QEMU 超时 60 秒。所有独立分支直接从 origin/develop@153578b5 开出,目标均为 develop;每个分支均独立完成 GCC 16.2 / LTO 构建,构建源只取 git ls-files '*.c',切分支后清除对应 .o/.d。按已知基线问题临时关闭 CONFIG_VIRTIO_GPU。除 strcpy PR 自身外,独立构建在链接命令临时加 -Wl,-u,strcpy,绕过原始 develop 的已复现 LTO 缺陷;没有把其他 PR 的源码带进分支。

运行基准时明确使用独立 sched 修复、strcpy 修复、kbench 和 kthread 绑定的共同测试覆盖层,以免把已知调度崩溃或实际 CPU 不符误算成待测修改的效果。覆盖层仅用于测试镜像,不构成提交依赖。

已否决方案:把偷取限制为源 rq 至少两个任务,曾使 ping-pong 约 3 µs 恶化到 7.8 µs;轮询 idle 无明显收益。这些改动均未采用。宿主负载高,仅把交替多次中位数中超过 20% 的差异视为性能结论。

🤖 Generated with ClaudeCode

A clean origin/develop build with GCC 16.2, CONFIG_VIRTIO_GPU disabled,
and only git ls-files '*.c' as C_SOURCES fails at the LTO link:
  kobject.c:605: undefined reference to strcpy
The failure is recorded in build/kbench/develop-clean-build.log.

GCC can introduce a strcpy call while lowering strcat in an LTO partition,
after whole-program analysis has removed the apparently unused definition.
Mark the kernel's strcpy definition used so the late reference resolves.
This follows the same retention technique used for freestanding memory
routines in U-Boot; it does not change strcpy's copy loop or ABI.

Validation: clean baseline link fails as above; this branch's standalone
GCC LTO build succeeds with the same configuration and tracked sources.
Runtime performance is unchanged by design; no performance gain is claimed.
No broader no-LTO or optimization-disable workaround is included.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@FengHeting

Copy link
Copy Markdown
Contributor

我们不应该去舔GCC的屁股(至少现在还没准备好)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants