Star2654
836
代码
代码
Issues79
Pull Requests70
项目讨论
Wiki
分析
Star2654
836
已开启
fix: lower ios-simulator LC_BUILD_VERSION threshold to 11.0 #600
睡觉对我很重要创建于 8月17日
fix: lower ios-simulator LC_BUILD_VERSION threshold to 11.0 #600
已开启
睡觉对我很重要创建于 8月17日
从weixin_44724691/llvm-projectfix_ios_simulator_lc_build_version合入到Cangjie/llvm-projectmain
睡觉对我很重要
睡觉对我很重要仓颉Developer
8月17日

llvm-project仓PR信息

变更内容**（必填）**

降低 LLD MachO useLCBuildVersion() 中 PLATFORM_IOSSIMULATOR 的部署版本门槛，由 13.0 调整为 11.0，并同步更新 lc-build-version.s 测试用例。

背景

cangjie_runtime#1688 为了让 iOS 11/12 老真机也能加载标准库，把部署版本从 17.5.0 降到 11.0.0（ast 用 12.0.0），该值同时被用于真机和模拟器分支。而 LLD 15.0.4 的 useLCBuildVersion() 对 PLATFORM_IOSSIMULATOR 设定了一个 13.0 的门槛：

  • 部署版本 ≥ 13.0 → 写 LC_BUILD_VERSION（带 platform=7 ios-simulator）
  • 部署版本 < 13.0 → 走旧分支，写 LC_VERSION_MIN_IPHONEOS（无平台字段）

于是 11.0.0/12.0.0 全部被压进 legacy 区间，dyld 按 LC_VERSION_MIN_IPHONEOS 推断成 iOS 真机镜像，导致模拟器加载标准库时报错。而本地 cjc 链接 main 时使用默认部署目标 17.5.0（高于 13.0），LLD 正常写出带 platform=ios-simulator 的 LC_BUILD_VERSION，所以同一个 LLD 在两边表现不同。

修复

iOS 模拟器实际运行在 macOS 宿主上，LC_BUILD_VERSION 的可解析性由 macOS 宿主决定（macOS 10.14+ 已支持），与 iOS 部署目标版本无关。部署目标只决定可用的 iOS API 集合，不决定 load command 格式。因此原先模拟器门槛 13.0 高于真机门槛 12.0 本身就是异常，对模拟器镜像使用 LC_VERSION_MIN_IPHONEOS 在语义上也是错误的（会让 dyld 误判为真机镜像）。

将模拟器门槛降到 11.0，使模拟器镜像即便在低部署目标下也写出带 platform=ios-simulator 的 LC_BUILD_VERSION；真机仍保持 12.0 门槛（iOS 12+ 才支持 LC_BUILD_VERSION）。

涉及文件

  • lld/MachO/Writer.cpp：useLCBuildVersion() 中 PLATFORM_IOSSIMULATOR 门槛 13.0 → 11.0
  • lld/test/MachO/lc-build-version.s：新增边界用例 ios-simulator 11.0 → LC_BUILD_VERSION、ios-simulator 12.0 由旧命令改为 LC_BUILD_VERSION，并补 ios-simulator 10.0 → LC_VERSION_MIN_IPHONEOS 覆盖门槛之下场景

变更类型**（必填）**

请描述本次Pull Request变更类型（原因），请在对应类型的括号内填写Y：

  • 新增需求（ ）
  • 问题修复（Y）
  • 构建过程或辅助工具变动（）
  • 文档更新（）

变更内容自检

编译器及标准库编译通过截图证明（如涉及新增需求、问题修复、构建过程变动需提供）

本次仅改动 LLD lld/MachO/Writer.cpp 一行门槛常量及对应测试，不涉及编译器/标准库主体逻辑。LLD 本地全量构建耗时较长未在此处附图，变更语义为一处常量下调，对编译路径无影响。

测试用例本地自验证通过截图证明（如涉及新增需求、问题修复需提供）

测试用例逻辑与门槛改动严格对齐：

  • ios-simulator 13.0/12.0/11.0 ≥ 11.0 → LC_BUILD_VERSION（IOS_12_0 前缀）
  • ios-simulator 10.0 < 11.0 → LC_VERSION_MIN_IPHONEOS（IOS_11_0 前缀）
  • 真机 ios 12.0/11.0 行为不变

本地 LLD 全量构建未完成，待作者补充 llvm-lit lld/test/MachO/lc-build-version.s 运行截图。

其他信息

根因不在链接器选错，而在 cangjie_runtime#1688 把部署版本调低后连带把模拟器压进了 LLD 的 legacy 区间。此处采用链接器侧根因修复（而非在 cangjie_runtime 的 cmake 里为模拟器单独抬到 ≥13），收益：不依赖上层构建脚本对模拟器/真机分支做特殊处理，所有使用 LLD 的模拟器产物在低部署目标下都能得到正确的 LC_BUILD_VERSION。
https://gitcode.com/Cangjie/cangjie_compiler/issues/541

likedislike
CLA协议签署
当前Pull Request的提交暂无外部代码贡献者
合并受阻
C
cangjie-ci成员
8月17日 评论：

PR创建成功通知 | 感谢您的贡献 🎉

您好！系统已检测到您成功创建 Pull Request（PR），感谢您对项目的支持与参与！以下几点需要您着重关注：

一、PR必须关联Issue ❗️

触发门禁检查的必要步骤：在PR描述框输入Issue完整链接，完成Issue关联。

请注意，一个 Issue 不能同时关联同一 base 仓库内同一个分支的多个开启状态的 PR

二、门禁触发规则 🔧

  1. 门禁类型判定：由Issue关联的PR所属代码仓数量决定
    • 关联多个代码仓PR：触发「多仓联合门禁」
    • 关联单个代码仓PR：触发「单仓门禁」
  2. 启动指令与检查范围：需主动回复指令：
    • 回复 "start build"：执行Cangjie的主要基础检查，包含commit格式检查、静态告警分析、OAT开源声明检查、多平台构建、单元/集成测试等
    • 关联同一issue的多个PR，仅需在任意一个PR里回复触发一次门禁，该PR门禁通过后，所有PR都会添加Label和测试人
    • 每个pr只能同时运行一条CI流水线，如需重新启动，请先关闭运行中的，再评论触发门禁
    • Markdown修改仅触发文档类构建测试门禁，不会触发Cangjie的编译测试门禁
    • commit 信息格式请遵循：Conventional Commits 规范
    • 请保证每一条 commit 都已添加 Signed-Off-By 信息
    • 回复 "start build cov"：执行覆盖率构建工程，生成该提交的增量代码覆盖率报告

三、合入条件 ⚠️

  • 满足最低评审人数，且评审问题需全部解决；
  • 禁止合入本人创建的PR，需由其他协作者操作；
  • 合并前确保关联流水线任务运行成功（build-test-passed）；
  • 需求类覆盖率门禁：当关联的 Issue 标题以 [feature]: 开头（需求类 Issue）时，联合提交中属于 cangjie_compiler、cangjie_runtime、cangjie_stdx、cangjie_tools、llvm-project 仓库的 PR，必须先回复 "start build cov" 触发增量覆盖率流水线并通过，使 PR 获得 cov-test-passed 标签后方可合入。

四、合并PR ✅

回复 "start merge"，CI流水线会自动检查所有关联PR的状态、版本号标签、检视意见密度、兼容性、需求类覆盖率门禁，若所有PR都满足合并条件，则将会同时合并所有PR。若存在不满足合并条件的PR，则不会合并任何PR。

如果希望不进行兼容性相关的检测，请任一合法审查人复制以下内容，在 start merge 前提交评论：

本 pr 不需要兼容性相关检测，对于引发的任何兼容性问题（即由于本 pr 合入将导致用户需适配代码的话），由本人承担。

If you wish to avoid compatibility-related checks, please have any approver copy the following content and submit it as a comment before sending start merge:

This PR does not require compatibility-related checks. For any compatibility issues caused by this PR (i.e., if the integration of this PR will require users to adapt their code), I will take full responsibility.

五、补充说明 📢

likedislike
Ccangjie-ci维护者
8月17日 添加了label：1.3.0-alpha.01waiting-start-build
Ccangjie-ci维护者
8月17日 重置了测试状态
睡觉对我很重要睡觉对我很重要仓颉Developer
8月17日 修改了pull request 的描述
睡觉对我很重要
睡觉对我很重要成员
8月17日 评论：

start build

likedislike
Ccangjie-ci维护者
8月17日 删除了label：waiting-start-build
Ccangjie-ci维护者
8月17日 添加了label：CI-running
C
cangjie-ci成员
8月17日 评论：

CI门禁流水线已启动，正在后台运行中，您可以点击Pipeline Detail查看运行状态。
门禁工作流：

graph LR
    A[PR检测] --> B[联合构建]
    B[联合构建] --> C[测试运行]

检查内容包括

  • commitlint检查
  • 构建任务
    • linux x64、mac aarch64、windows x64
  • 测试任务
    • UT、HLT、LLT

门禁产物归档路径: obs://cangjie103/CangjieDaily/pub/ci/gate/main/llvm-project/600

likedislike
Ccangjie-ci维护者
8月17日 添加了label：commitlint-passedsign-off-passed
Ccangjie-ci维护者
8月17日 添加了label：OAT-passed
Ccangjie-ci维护者
8月17日 添加了label：codecheck-passed
C
cangjie-ci成员
8月17日 评论：

⚠️ 构建/测试失败，请点击 🔍 Pipeline Detail 查看完整错误信息

📄 任务详细日志：

平台 类型 任务 状态 日志链接
🐧 linux 🔨 build - ✅ 📋 查看
🐧 linux 🧪 test HLT_cjdb ✅ 📋 查看
🐧 linux 🧪 test HLT_cjc_libs ✅ 📋 查看
🐧 linux 🧪 test HLT_cjcov ✅ 📋 查看
🐧 linux 🧪 test HLT_cjfmt ✅ 📋 查看
🐧 linux 🧪 test HLT_cjlint ✅ 📋 查看
🐧 linux 🧪 test HLT_cjpm ✅ 📋 查看
🐧 linux 🧪 test HLT_lsp ✅ 📋 查看
🐧 linux 🧪 test HLT_cjprof ✅ 📋 查看
🐧 linux 🧪 test LLT_cjc_libs ✅ 📋 查看
🐧 linux 🧪 test LLT_cjfmt ✅ 📋 查看
🐧 linux 🧪 test LLT_cjpm ✅ 📋 查看
🐧 linux 🧪 test LLT_hle ✅ 📋 查看
🐧 linux 🧪 test LLT_lsp ❌ 📋 查看
🐧 linux 🧪 test LLT_cjprof ✅ 📋 查看
🐧 linux 🧪 test LLT_cjcompat ✅ 📋 查看
🍎 mac 🔨 build - ✅ 📋 查看
🍎 mac 🧪 test - ✅ 📋 查看
🪟 windows 🔨 build - ✅ 📋 查看
🪟 windows 🧪 test - ✅ 📋 查看
likedislike
Ccangjie-ci维护者
8月17日 删除了label：CI-running
此处折叠了5条事件消息 查看更多
Ccangjie-ci维护者
8月17日 通过测试
C
cangjie-ci成员
8月17日 评论：

您提交的 PR 已顺利通过全部门禁检查流程，当前状态符合合入标准✅。具体检查结果如下：

  • Commit 检查：代码提交信息规范性、完整性、Signed Off信息验证通过，无格式或逻辑问题✓；
  • 代码构建：编译过程无报错，依赖项加载正常，构建产物完整性达标🔧；
  • 测试验证：单元测试、集成测试等各类用例执行完毕，全部通过验证🧪。

目前该 PR 已完全具备合入条件，可按项目流程推进后续合入操作。感谢您的严谨开发与协作，期待代码顺利合入🎉！

likedislike
Ccangjie-ci维护者
8月17日 删除了label：CI-running
Ccangjie-ci维护者
8月17日 添加了label：build-test-passed