Chromium 定制版 PGO 实战：Chrome 与 V8 Builtins 两套体系以及打包踩坑

关注

原创最新推荐文章于 2026-09-26 20:39:11 发布 390 阅读 AI 写同款· GEO 优化 ›

chromium ARM版本编译记录刚开始想着一步到位直接在阿里云香港主机上买高配置的竞价虚拟机，结果居然编译不过，老是报有个东西没安装，试了好几次都不行，本来都计划放弃了的。我机器编译大概一两个小时，看机器配置，编译完成后，网上很多文章说直接运行chrome就行，但我拷贝到飞腾机器上直接运行报错。这个过程报了个错,看了下是拉谷歌字体的时候用的个Py调用的curl，Py里面没法把环境变量的代理传进去，手工编辑下。原因是部分通用的H264 解码codec没编译进去，解决办法就是在生成配置的时候添加2个参数重新编译就好了。接下来开始配置并编译。阅读详情

本文基于一次真实升核（M148 / V8 14.8.x）打包与 PGO 训练整理

前言：为什么 PGO 会「编着编着就缺文件」

切到 Official Release + PGO Phase 2 后，常见报错：

../../v8/tools/builtins-pgo/profiles/x64-rl.profile

needed by snapshot_blob.bin -> gen/v8/embedded.S

missing and no known rule to make it

这往往不是 snapshot 坏了，而是 Chrome 主程序 PGO 与 V8 Builtins PGO 是两套机制：只提交了 Chrome 的 *.profdata，却默认打开了 V8 builtins 优化，构建在 schedule 阶段就失败。

一、两套 PGO：别混成一个「PGO 包」

	Chrome PGO	V8 Builtins PGO
优化对象	`chrome.dll` 等 C++	V8 builtins（`mksnapshot` / snapshot）
训练产物	`*.profdata`	`x64-rl.profile` 等
训练工具	`tools/pgo/generate_profile.py`	官方下载或 `v8/tools/builtins-pgo/generate.py`
Phase 2 开关	`chrome_pgo_phase=2`	`v8_enable_builtins_optimization=true`（Phase 2 默认常开）

is_official_build=true

→ chrome_pgo_phase=2

→ v8_enable_builtins_optimization 默认为 true（若未显式关闭）

→ Windows x64 需要 x64-rl.profile

Chrome profdata 有了 ≠ V8 profile 有了。

二、Chrome PGO：Phase 1 与 Phase 2

Phase 1：插桩采集

GN：chrome_pgo_phase=1
编译带 -fprofile-generate
插桩版浏览器跑 benchmark → .profraw → llvm-profdata merge → profile.profdata

python3 tools/pgo/generate_profile.py -C out/PGOPhase1

需要完整源码树 + Phase 1 输出目录，不能只有二进制。

Phase 2：用 profile 优化

-fprofile-use=...profdata + ThinLTO
链接 chrome.dll 通常最慢
CI 若每次 clean 全量，每次都像第一次全编

三、Phase 1 链接坑：升核后 fork 与上游 API 类型不一致

Phase 1 除了「能编过、能跑 benchmark」，还可能遇到链接阶段才暴露的问题。下面是一次 M148 升核 + chrome_pgo_phase=1 时的案例（扩展工具栏 ViewModel），与 V8 profile 无关，但不做修复就过不了 Phase 1，也就训不出 Chrome profdata。

3.1 现象

在 args.gn 中设置：

chrome_pgo_phase = 1

# fork 定制宏已开启（如扩展工具栏仍走 vector 顺序语义）

执行：

autoninja -C out/Release chrome

chrome.dll 链接失败，lld-link 报 undefined symbol，符号栈与 base::flat_tree / flat_set 析构相关——表面看像 STL 或 libc++ 链接问题，实际是接口返回类型与底层实现不一致在 PGO 插桩下被放大。

3.2 根因（148 上游 vs fork 历史行为）

148 上游把 ExtensionsToolbarViewModel::GetAllActionIds() 改成了返回 const base::flat_set<ActionId>&，与 ToolbarActionsModel::action_ids() 对齐。

定制 fork 在产品宏分支下仍保留 ToolbarActionsModel::action_ids() 返回 std::vector<ActionId>&（扩展工具栏顺序语义依赖 vector，而非 sorted flat_set）。

若 ViewModel 仍声明返回 flat_set&，实现里却 return actions_model_->action_ids()：

编译器对 vector → flat_set 做隐式转换，构造临时 flat_set
函数返回的是临时对象的引用（本身已是危险写法）
PGO Phase 1 插桩下，flat_tree 析构路径无法如 Release 那样内联
链接器找不到对应符号 → chrome.dll 链接失败

非 PGO 或 Phase 0 构建有时能「侥幸过」或表现不同；Phase 1 是更严格的照妖镜。

3.3 修复思路（与上游分叉的最小对齐）

在 fork 宏分支让声明、实现与底层同一类型——返回 const std::vector<ActionId>&，直接转发 action_ids()，避免任何 vector→flat_set 临时对象：

#ifdef FORK_EXTENSIONS_TOOLBAR /* 示意：你们实际的 fork 宏名 */

const std::vector<ToolbarActionsModel::ActionId>&

ExtensionsToolbarViewModel::GetAllActionIds() const {

return actions_model_->action_ids();

}

#else

const base::flat_set<ToolbarActionsModel::ActionId>&

ExtensionsToolbarViewModel::GetAllActionIds() const {

return actions_model_->action_ids();

}

#endif

HasAnyExtensions() 在 fork 分支改为直接读 action_ids().empty()，不要再经可能触发转换的 GetAllActionIds()：

bool ExtensionsToolbarViewModel::HasAnyExtensions() const {

#ifdef FORK_EXTENSIONS_TOOLBAR

return !actions_model_->action_ids().empty();

#else

return !GetAllActionIds().empty();

#endif

}

头文件同步改返回类型，并加注释说明：禁止在 fork 路径返回 flat_set&，否则 PGO 链接可能再炸。

3.4 测试建议

项	做法
链接	`chrome_pgo_phase=1`，`autoninja -C out/Release chrome`，确认 chrome.dll 链接通过
功能	启动浏览器：扩展工具栏图标显示、拖拽、溢出菜单
回归	Phase 0 / Phase 2 各编一次，确认无新增链接错误

3.5 对 PGO 流程的启示

升核 → 先过 Phase 1 链接 + 能启动

→ 再 generate_profile.py 训 profdata

→ 再 Phase 2 + V8 profile

Phase 1 链接问题和 Phase 2 缺 x64-rl.profile 是不同阶段、不同层的故障：

阶段	典型错误	性质
Phase 1	lld-link undefined symbol（flat_set/flat_tree）	fork 与 148 API 类型不一致 + 插桩
Phase 2	missing x64-rl.profile	V8 builtins PGO 文件缺失