Welcome To openEuler Community
Hey @always_flipped_1 , thanks for your contribution to the community.
Bot Usage Manual
I'm the Bot here serving you. You can find the instructions on how to interact with me at Here . That means you can comment below every pull request or issue to trigger Bot Commands.
Contact Guide
If you have any questions, please contact the SIG: Compiler ,
and any of the maintainers: @SegFault, @alexanderbill, @cf-zhao, @chenzheng1030, @eastb233, @kuenking111_admin, @li-yancheng, @wangqiang95, @wd-gitcode ,
and any of the committers: @huang-xiaoquan, @huzife, @lin-4682, @xiongzhou4 .


问题根因:Gis_wkb_vector
| 位置 | 内容 |
|---|---|
| spatial.h:2359 | void set_ptr(void *ptr, size_t len); —— 类模板内声明 |
| spatial.cc:4738 | template |
| spatial.cc:5148 | 实例化覆盖了 clear / push_back / reassemble / resize / shallow_push / 构造函数 / operator=,唯独没有 set_ptr |
后果是:
- item_geofunc_setops.cc 只看得到 spatial.h:2359 的声明,看不到定义,因此无法自行实例化,只能发一个未定义外部引用出去;
- spatial.cc 里之所以有这个符号,纯属隐式实例化的副产品——parse_wkb_data(spatial.cc:3907,声明在 spatial.h:2120)在 spatial.cc:4112 对 Gis_polygon_ring *outer 调了 outer->set_ptr(q, nbytes),而 Gis_polygon_ring : public Gis_wkb_vector<Gis_point>(spatial.h:2424)且自己没有重声明 set_ptr,这一句就把 Gis_wkb_vector<Gis_point>::set_ptr 隐式实例化了出来;
- 隐式实例化出来的模板函数是 COMDAT/weak 符号。编译器对 COMDAT 的假设是「谁需要谁自己再生成一份」,所以一旦本 TU 内没有直接调用者了,把离线副本丢掉是完全合法的。
这个假设在这里不成立——因为定义不在头里,别的 TU 生成不出来。按标准这属于 IFNDR,编译器不必诊断。所以严格说这是 MySQL/Percona 的源码缺陷,只是一直被"优化不够激进、恰好没把最后一个调用点消除掉"掩盖着。CFGO调整了内联和ipa优化参数,正好触发这个场景,换个优化级别或者编译器也可能出现;
推荐修复:在spatial.cc中补上实例化流程


问题概述
使用 openEuler GCC 12.3.1 2025.06 的 AutoCFGO 流程构建 Percona Server 5.7.44 时,
05-build-cfgo-cspgo阶段在最终链接mysqld时失败:该错误来自 GIS 几何相关模板代码。调用方位于
sql/item_geofunc_setops.cc,而应提供该符号的实现位于sql/spatial.cc。在失败阶段生成的libsql.a中,item_geofunc_setops.cc.o保留了对该符号的未定义引用,但spatial.cc.o没有导出对应定义,最终导致mysqld链接失败。问题只在 CFGO-CSPGO 的 profile-use 构建阶段暴露,前面的原生构建、CFGO-PGO 插桩构建和 PGO 运行均成功。
环境
操作系统和架构
编译器
CFGO 相关源码提交:
数据库版本
构建配置
复现流程
执行完整 AutoCFGO 流程。
阶段结果:
01-build-raw02-run-raw03-build-cfgo-pgo04-run-cfgo-pgo05-build-cfgo-cspgomysqld时失败06-run-cfgo-cspgo及之后第五阶段 Wrapper 注入的关键参数为:
失败日志
链接
mysqld时的主要错误如下:相关调用函数包括:
符号级定位
对失败阶段生成的静态库进行符号检查:
观察结果:
因此当前可以确认:
item_geofunc_setops.cc.o生成了对Gis_wkb_vector<Gis_point>::set_ptr的引用;spatial.cc.o没有生成或保留对应的可链接定义;触发范围和当前判断
03-build-cfgo-pgo阶段只启用:该阶段构建和运行均成功。
05-build-cfgo-cspgo阶段同时启用:该阶段在链接
mysqld时失败。因此目前最可疑的是 PGO use 与 CSPGO generate 组合触发的 IPA/内联/模板符号生成问题,而不是 profile 文件损坏或 workload 运行失败。当前还不能断言根因一定是某个单独 GCC pass,也不能排除该模板代码在激进跨过程优化下缺少显式实例化或出现 COMDAT/弱符号处理问题。需要进一步确认。
临时规避
已验证的工程侧规避方向是:只对
sql/spatial.cc关闭可能导致符号消失的 IPA 和内联 pass,保留其余翻译单元的 CFGO 优化:可以通过现有 CMake 按文件追加参数:
如果同时构建
libmysqld目标,还需要对对应路径的../sql/spatial.cc使用相同设置。期望结果
在启用:
时,Percona Server 的
mysqld应能够正常完成编译和链接。由sql/spatial.cc提供的:应与
sql/item_geofunc_setops.cc的调用保持一致,不应出现 undefined reference。希望协助确认
sql/spatial.cc中错误删除、隐藏或未实例化Gis_wkb_vector<Gis_point>::set_ptr的可链接定义。nm -C、GIMPLE/RTL dump 以及最终符号可见性。-fcfgo-profile-use + -fcfgo-csprofile-generate + -fprofile-correction是否是必要触发条件,并建议最小化的独立复现参数。-fipa-cp-clone、-fipa-cp和内联优化是否是可靠方案。Gis_wkb_vector<T>::set_ptr的跨翻译单元模板实例化构造独立 AArch64 GCC testcase,以便后续定位和修复。