feat(starry): add jcode app case for x86_64 QEMU#988
Conversation
![mai-team-app[bot]](https://avatars.githubusercontent.com/u/34859362?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR 审查：feat(starry): add jcode app case for x86_64 QEMU
变更概述
本 PR 在 apps/starry/jcode/ 下新增了一个操作者面向的 jcode (AI coding agent) 工作流，包含：
- 下载 jcode 二进制并从 GitHub releases 获取
- 使用 patchelf + qemu-user 将 glibc 链接的二进制转换为 musl 兼容
- 构建 glibc stub 共享库（
libglibc_stub.so）提供mallopt、__res_init等 glibc-only 符号 - 将 jcode 注入 rootfs 镜像并提供 QEMU smoke 测试配置
文件结构遵循 apps/starry/ 下已有的 codex-cli、deepseek-tui、picoclaw-cli 模式，放置位置正确。
阻塞问题：glibc stub 汇编存根参数移位错误
prepare_jcode_assets.sh 中的 glibc stub 汇编代码有多个 __*_chk 函数存根存在 x86-64 System V ABI 参数移位错误。这些函数是 _FORTIFY_SOURCE 编译产物，在运行时会被实际调用（如 jcode 的 C 依赖 libssl/libcrypto/krb5），不正确的参数传递会导致格式化字符串解析错误、fread 读取错误等运行时故障。
详见 inline comments。
CI 状态
所有 CI checks 状态为 skipped（因为 PR 仅触及 apps/starry/ 目录）。CI 不覆盖此 PR 的变更面。
Shell 脚本验证
bash -n语法检查：三个 shell 脚本均通过 ✓- shellcheck 不可用，无法运行静态分析
- SHA256 校验机制完整，下载 URL 和版本号均有固定 ✓
重复/重叠分析
- dev 分支上无 jcode 相关代码 ✓
- dev 分支上已有
codex-cli、deepseek-tui、picoclaw-cli等类似 app 工作流，本 PR 遵循相同模式 ✓ - 未发现与当前 open PR 的冲突或重叠 ✓
- glibc-to-musl binary patching 是本 PR 独有的创新点
其他观察
- README 中提到计划在
test-suit/starryos/normal/qemu-smp1/jcode/添加 CI 测试，但本 PR 不包含。作为操作者面向的 app 工作流，这是可接受的，但建议后续 PR 补充 CI 覆盖。 - QEMU 配置中的
success_regex和fail_regex设计合理。
建议
修复所有 __*_chk 存根的参数移位后，本 PR 可以 approve。
Powered by mimo-v2.5-pro
| '' \ | ||
| '.globl __sprintf_chk' \ | ||
| '.type __sprintf_chk, @function' \ | ||
| '__sprintf_chk: mov %rcx, %rsi; jmp sprintf@PLT' \ |
There was a problem hiding this comment.
存根参数移位错误：__sprintf_chk(char *str, int flag, const char *format, ...) 的寄存器布局为 rdi=str, esi=flag, rdx=format, rcx=first_vararg。应映射到 sprintf(str, format, ...) 即 rdi=str, rsi=format, rdx=first_vararg。
当前 mov %rcx, %rsi 将 first_vararg 放入 rsi（应为 format），而 rdx 保持 format（应为 first_vararg），format 和第一个参数互换了。
应改为：
'__sprintf_chk: mov %rdx, %rsi; mov %rcx, %rdx; jmp sprintf@PLT'
| '' \ | ||
| '.globl __fread_chk' \ | ||
| '.type __fread_chk, @function' \ | ||
| '__fread_chk: mov %r8, %rcx; jmp fread@PLT' \ |
There was a problem hiding this comment.
存根参数移位不完整：__fread_chk(void *ptr, size_t ptrlen, size_t size, size_t nmemb, FILE *stream) 的寄存器布局为 rdi=ptr, rsi=ptrlen, rdx=size, rcx=nmemb, r8=stream。应映射到 fread(ptr, size, nmemb, stream) 即 rdi=ptr, rsi=size, rdx=nmemb, rcx=stream。
当前只做了 mov %r8, %rcx（stream→rcx），但 rsi 仍为 ptrlen（应为 size），rdx 仍为 size（应为 nmemb）。会导致 fread 读取 ptrlensize 字节而非 sizenmemb 字节。
应改为：
'__fread_chk: mov %rdx, %rsi; mov %rcx, %rdx; mov %r8, %rcx; jmp fread@PLT'
| '' \ | ||
| '.globl __syslog_chk' \ | ||
| '.type __syslog_chk, @function' \ | ||
| '__syslog_chk: mov %rdx, %rsi; jmp syslog@PLT' \ |
There was a problem hiding this comment.
存根参数移位不完整：__syslog_chk(int priority, int flag, const char *format, ...) 的寄存器布局为 rdi=priority, esi=flag, rdx=format, rcx=first_vararg。应映射到 syslog(priority, format, ...) 即 rdi=priority, rsi=format, rdx=first_vararg。
当前 mov %rdx, %rsi 正确将 format 移入 rsi，但 rdx 仍为 format（应为 first_vararg）。syslog 将收到 (priority, format, format, ...) 而非 (priority, format, first_vararg, ...)。
应改为：
'__syslog_chk: mov %rdx, %rsi; mov %rcx, %rdx; jmp syslog@PLT'
| '' \ | ||
| '.globl __fprintf_chk' \ | ||
| '.type __fprintf_chk, @function' \ | ||
| '__fprintf_chk: mov %rdx, %rsi; jmp fprintf@PLT' \ |
There was a problem hiding this comment.
同样的参数移位不完整问题：__fprintf_chk(FILE *stream, int flag, const char *format, ...) 的寄存器布局为 rdi=stream, esi=flag, rdx=format, rcx=first_vararg。应映射到 fprintf(stream, format, ...) 即 rdi=stream, rsi=format, rdx=first_vararg。
当前 mov %rdx, %rsi 将 format 移入 rsi，但 rdx 仍为 format（应为 first_vararg）。
应改为：
'__fprintf_chk: mov %rdx, %rsi; mov %rcx, %rdx; jmp fprintf@PLT'
There was a problem hiding this comment.
PR 审查：feat(starry): add jcode app case for x86_64 QEMU
变更概述
本 PR 在 apps/starry/jcode/ 下新增了操作者面向的 jcode (AI coding agent) 工作流，包含：
- 从 GitHub releases 下载 jcode 二进制并校验 SHA256
- 使用 patchelf + qemu-user 将 glibc 链接的 jcode 转换为 musl 兼容
- 构建 glibc stub 共享库（
libglibc_stub.so）提供mallopt、__res_init等 glibc-only 符号 - 将 jcode 注入 rootfs 镜像并提供 QEMU smoke 测试配置
文件结构完全遵循 apps/starry/ 下已有的 codex-cli、deepseek-tui、picoclaw-cli 模式，放置位置正确。
前轮 review 修复确认
上一轮 review (mai-team-app[bot]) 在旧提交 bc21b8d4 上指出 glibc stub 汇编代码存在参数移位错误。当前 HEAD cdf6fc63 已修复所有 __*_chk 存根的 x86-64 System V ABI 参数映射：
__fprintf_chk(flag→rsi移除, format→rsi, vararg→rdx)✓__printf_chk(flag→rdi移除, format→rdi, vararg→rsi)✓__vfprintf_chk(flag→rsi移除, format→rsi, va_list→rdx)✓__sprintf_chk(flag→rsi移除, format→rsi, vararg→rdx)✓__memcpy_chk(destlen忽略)✓__memset_chk(destlen忽略)✓__strcat_chk(destlen忽略)✓__fread_chk(ptrlen→rsi, size→rsi via rax, nmemb→rdx, stream→rcx)✓__syslog_chk(flag→rsi移除, format→rsi, vararg→rdx)✓
所有存根参数映射现在符合 x86-64 System V ABI，前轮阻塞问题已解决。
Shell 脚本验证
bash -n语法检查：prepare_jcode_assets.sh、prepare_jcode_rootfs.sh、prebuild.sh均通过 ✓- SHA256 校验机制完整，下载 URL 和版本号均已固定 ✓
- 临时目录通过 trap cleanup 正确清理 ✓
CI 状态
CI checks 状态均为 skipped（PR 仅触及 apps/starry/ 目录），符合预期。
重复/重叠分析
- dev 分支上无 jcode 相关代码 ✓
- dev 分支上已有 codex-cli、deepseek-tui、picoclaw-cli 等类似 app 工作流，本 PR 遵循完全相同的 QEMU 配置和目录结构 ✓
- open PR #984 (macos-selfbuild)、#931 (gdb-smoke)、#945 (gcc test) 各自添加不同的
apps/starry/子目录，无冲突或重叠 ✓ - glibc-to-musl binary patching 是本 PR 独有的创新点
代码质量观察
- QEMU 配置中
success_regex和fail_regex设计合理，与 codex-cli/deepseek-tui 一致 - README 完整说明了 host 依赖、rootfs 准备、离线 smoke 测试和手动交互方式
JCODE_NO_AUTO_UPDATE=1环境变量防止自动更新覆盖已打补丁的 musl 版本二进制，设计合理prebuild.sh有缓存逻辑（rootfs 已存在时跳过重建），适合开发迭代- README 明确声明本目录是操作者面向工作流，不是 CI 用例
建议
前轮 review 的阻塞问题已全部修复，本 PR 可以 approve。README 中提到计划在 test-suit/starryos/normal/qemu-smp1/jcode/ 添加 CI 测试用例，建议后续 PR 补充 CI 覆盖。
Powered by mimo-v2.5-pro
|
已去掉README中提到test-suit |
There was a problem hiding this comment.
PR 审查：feat(starry): add jcode app case for x86_64 QEMU
变更概述
本 PR 在 apps/starry/jcode/ 下新增了操作者面向的 jcode (AI coding agent) 工作流，包含：
- 从 GitHub releases 下载 jcode 二进制并校验 SHA256
- 使用 patchelf + qemu-user 将 glibc 链接的 jcode 转换为 musl 兼容
- 构建 glibc stub 共享库（
libglibc_stub.so）提供mallopt、__res_init等 glibc-only 符号 - 将 jcode 注入 rootfs 镜像并提供 QEMU smoke 测试配置
文件结构完全遵循 apps/starry/ 下已有的 codex-cli、deepseek-tui、picoclaw-cli 模式，放置位置正确。
glibc stub 汇编验证
手动逐行验证了所有 9 个 __*_chk 存根的 x86-64 System V ABI 参数映射：
| 存根 | 签名 → 目标 | 寄存器移位 | 结论 |
|---|---|---|---|
__fprintf_chk |
(stream,flag,fmt,...) → (stream,fmt,...) |
mov %rdx,%rsi; mov %rcx,%rdx |
✓ |
__printf_chk |
(flag,fmt,...) → (fmt,...) |
mov %rsi,%rdi; mov %rdx,%rsi |
✓ |
__vfprintf_chk |
(stream,flag,fmt,ap) → (stream,fmt,ap) |
mov %rdx,%rsi; mov %rcx,%rdx |
✓ |
__sprintf_chk |
(str,flag,fmt,...) → (str,fmt,...) |
mov %rdx,%rsi; mov %rcx,%rdx |
✓ |
__memcpy_chk |
(dest,src,len,destlen) → (dest,src,len) |
直接跳转（忽略 rcx） | ✓ |
__memset_chk |
(s,c,len,destlen) → (s,c,len) |
直接跳转（忽略 rcx） | ✓ |
__strcat_chk |
(dest,src,dlen) → (dest,src) |
直接跳转（忽略 rdx） | ✓ |
__fread_chk |
(ptr,ptrlen,size,nmemb,stream) → (ptr,size,nmemb,stream) |
mov %rdx,%rax; mov %rcx,%rdx; mov %r8,%rcx; mov %rax,%rsi |
✓ |
__syslog_chk |
(prio,flag,fmt,...) → (prio,fmt,...) |
mov %rdx,%rsi; mov %rcx,%rdx |
✓ |
所有存根参数映射正确，__fread_chk 使用 rax 作为临时寄存器避免数据覆盖，处理得当。
Shell 脚本验证
bash -n语法检查：prepare_jcode_assets.sh、prepare_jcode_rootfs.sh、prebuild.sh均通过 ✓- SHA256 校验机制完整，下载 URL 和版本号均已固定 ✓
- 临时目录通过
trap cleanup EXIT正确清理 ✓ set -euo pipefail全部启用 ✓
CI 状态
所有 CI check runs 状态均为 skipped（PR 仅触及 apps/starry/ 目录），符合预期。
重复/重叠分析
- dev 分支上无 jcode 相关代码 ✓
- dev 分支上已有 codex-cli、deepseek-tui、picoclaw-cli 等类似 app 工作流，本 PR 遵循完全相同的 QEMU 配置和目录结构 ✓
- open PR 中未发现与本 PR 的文件冲突或功能重叠 ✓
- glibc-to-musl binary patching + stub .so 注入是本 PR 独有的创新点
代码质量
- QEMU 配置中
success_regex和fail_regex设计合理 - README 完整说明了 host 依赖、rootfs 准备、离线 smoke 测试和手动交互方式
JCODE_NO_AUTO_UPDATE=1防止自动更新覆盖已打补丁的 musl 版本二进制prebuild.sh有缓存逻辑（rootfs 已存在时跳过重建）- README 明确声明本目录是操作者面向工作流，不是 CI 用例 ✓
建议
无阻塞问题，本 PR 可以 approve。
Powered by mimo-v2.5-pro
ZR233
left a comment
ZR233
left a comment
There was a problem hiding this comment.
本次复核重点验证新增 apps/starry/jcode app 场景是否能按 PR 描述实际运行。
PR 新增了 jcode 的手动 rootfs 准备脚本、资产补丁脚本、QEMU smoke 配置和 app-run 相关文件。放在 apps/starry/jcode/ 下符合 operator-facing app 场景定位；base 分支没有现有 apps/starry/jcode，相关搜索只命中已关闭的早期同名 PR #977 和已合入的 jcode 前置内核修复，没有发现当前 open PR 的直接文件冲突。当前 GitHub CI 常规矩阵成功，但没有覆盖这个手动下载、patch、rootfs 注入和 jcode smoke 的流程。
实际验证了两个入口：
apps/starry/jcode/prepare_jcode_rootfs.sh该命令先成功准备了默认 x86_64 Alpine base rootfs。宿主机原本缺少 patchelf，我用本地 .deb 解包方式临时提供 patchelf 后继续执行；随后脚本下载 jcode-linux-x86_64.tar.gz，但在 SHA 校验处失败：
expected: aa53838dd0014e368f55dd8dd4bd2a092d60dbe2bf451560ed00b18d0a298022
actual: cc7fef26c348124af40db1793481b46945842e20a7b6c684fc66bea7b2524f0b
删除缓存重下后 hash 仍是 cc7fef26...，并且上游 v0.12.0 release 的 SHA256SUMS 中 jcode-linux-x86_64.tar.gz 也是这个值。因此当前 README 声明的 rootfs 准备流程不可复现，QEMU smoke 还没机会运行。
另外验证了 app runner 入口：
PATH="$PWD/target/host-tools/patchelf/usr/bin:$PATH" cargo xtask starry app run -t jcode --arch x86_64该入口同样失败：prebuild.sh 看到 rootfs-x86_64-jcode.img 已存在后直接退出，STARRY_OVERLAY_DIR 仍为空，随后 app runner 注入 overlay 报错：
jcode rootfs already exists: .../rootfs-x86_64-jcode.img
To rebuild, remove it first or run prepare_jcode_rootfs.sh directly.
Error: overlay injection source is empty: .../tmp/axbuild/starry-app/jcode/overlay
因此当前 PR 同时存在两个阻塞点：README 的手动两步流程被错误 SHA 卡住，cargo xtask starry app run -t jcode 入口也不符合 app runner 的 overlay 约定。请先修复 SHA 并重新跑通 README 中的 rootfs 准备 + QEMU smoke；同时需要决定是否正式支持 starry app run -t jcode，若支持则让 prebuild.sh 产出 overlay 给 app runner 注入，若不支持则避免暴露一个稳定失败的 app-run 入口。
Add an operator-facing jcode (AI coding agent) workflow under apps/starry/jcode/. The two-stage pipeline downloads jcode from GitHub releases, patches the glibc binary for musl via patchelf + qemu-user, builds a glibc stub .so, and injects everything into a dedicated rootfs image. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
There was a problem hiding this comment.
PR 审查：feat(starry): add jcode app case for x86_64 QEMU
变更概述
本 PR 在 apps/starry/jcode/ 下新增了操作者面向的 jcode (AI coding agent) 工作流，包含：
- 从 GitHub releases 下载 jcode 二进制并校验 SHA256
- 使用 patchelf + qemu-user 将 glibc 链接的 jcode 转换为 musl 兼容
- 构建 glibc stub 共享库（
libglibc_stub.so）提供mallopt、__res_init等 glibc-only 符号 - 将 jcode 注入 rootfs 镜像并提供 QEMU smoke 测试配置
文件结构完全遵循 apps/starry/ 下已有的 codex-cli、deepseek-tui、picoclaw-cli 模式，放置位置正确。
前轮 review 修复确认
上一轮 ZR233 的 review 指出了两个阻塞问题：
- SHA256 不匹配：脚本中的
JCODE_SHA256与实际下载的 tarball hash 不一致。当前 HEAD (ee366c13) 中已修复为cc7fef26c348124af40db1793481b46945842e20a7b6c684fc66bea7b2524f0b，该值与上游 v0.12.0 release 的SHA256SUMS一致。 cargo xtask starry app run -t jcode入口失败：旧版prebuild.sh在 rootfs 已存在时提前退出且不产出 overlay。当前版本中prebuild.sh不再调用prepare_jcode_rootfs.sh，而是调用prepare_jcode_assets.sh并直接填充STARRY_OVERLAY_DIR，不再有提前退出的逻辑。
前轮 mai-team-app[bot] 指出的 glibc stub 汇编 ABI 参数移位问题也已在之前提交中全部修复并验证通过。
本次验证
- Shell 语法检查：
prepare_jcode_assets.sh、prepare_jcode_rootfs.sh、prebuild.sh均通过bash -n✓ - 资产准备：
prepare_jcode_assets.sh运行成功——jcode v0.12.0 tarball 下载并通过 SHA256 校验，Alpine minirootfs 下载并通过 SHA256 校验，glibc stub.so构建成功，所有资产正确输出到target/jcode/assets/✓ - Rootfs 注入：使用
debugfs将 jcode 资产注入 ext4 rootfs，/usr/lib/jcode/jcode.bin、/usr/lib/jcode/libglibc_stub.so、/usr/bin/jcode均正确写入 ✓ - Starry 内核构建：
cargo xtask starry build --arch x86_64构建成功 ✓ - QEMU smoke 测试：未能正常运行，但确认是 Docker 环境限制（即使是 base Alpine rootfs 也因
axfs-ng无法识别 virtio-blk 设备而 panic），非本 PR 引入的问题。ZR233 在上一轮 review 中也未能完成 QEMU smoke 验证（被 SHA256 卡住），建议在具备 KVM 的物理机或 CI 环境中进行补充验证。
重复/重叠分析
- dev 分支上无 jcode 相关代码 ✓
- open PR 中未发现与本 PR 的文件冲突或功能重叠（PR #1004 为 futex 测试、PR #1005 为 SVM 增强） ✓
- glibc-to-musl binary patching + stub .so 注入是本 PR 独有的创新点，在
apps/starry/下没有其他 app 使用类似技术
CI 状态
所有 CI checks 均为 skipped（PR 仅触及 apps/starry/ 目录），符合预期。
代码质量
- QEMU 配置中
success_regex和fail_regex设计合理，与 codex-cli/deepseek-tui 一致 - README 完整说明了 host 依赖、rootfs 准备、离线 smoke 测试和手动交互方式
JCODE_NO_AUTO_UPDATE=1防止自动更新覆盖已打补丁的 musl 版本二进制- README 明确声明本目录是操作者面向工作流，不是 CI 用例，符合
apps/starry/定位 - 临时目录通过
trap cleanup EXIT正确清理 set -euo pipefail全部启用
审查结论
无阻塞问题，本 PR 可以 APPROVE。建议作者在后续 PR 中补充以下内容：
- 在有 KVM 支持的 CI 环境中完成 QEMU smoke 测试截图/日志作为验证证据
- 如需正式支持
cargo xtask starry app run -t jcode入口，确保prebuild.sh产出的 overlay 与 app runner 的注入约定一致
Powered by mimo-v2.5-pro
Powered by deepseek-v4-pro
ZR233
left a comment
ZR233
left a comment
There was a problem hiding this comment.
本轮按当前 HEAD ee366c1314b8ce57e3c1c4aa5229503965995207 重新做了实际 app 运行验证。
已确认上一轮提出的两个阻塞点在当前提交中修复：
JCODE_SHA256已更新为上游 v0.12.0 release 的实际值cc7fef26c348124af40db1793481b46945842e20a7b6c684fc66bea7b2524f0b。prebuild.sh现在会填充STARRY_OVERLAY_DIR，不再因为已有rootfs-x86_64-jcode.img而留下空 overlay。
本地验证结果：
bash -n apps/starry/jcode/prebuild.sh \
apps/starry/jcode/prepare_jcode_assets.sh \
apps/starry/jcode/prepare_jcode_rootfs.sh通过。
PATH="$PWD/target/host-tools/patchelf/usr/bin:$PATH" \
apps/starry/jcode/prepare_jcode_rootfs.sh通过并生成 tmp/axbuild/rootfs/rootfs-x86_64-jcode.img。宿主机没有全局 patchelf，这里使用本地解包的 patchelf 放进 PATH 后验证；apk 会打印目录权限相关告警，但命令退出码为 0，资产和 rootfs 均生成成功。
PATH="$PWD/target/host-tools/patchelf/usr/bin:$PATH" \
cargo xtask starry qemu \
--arch x86_64 \
--qemu-config apps/starry/jcode/qemu-x86_64.toml \
--rootfs tmp/axbuild/rootfs/rootfs-x86_64-jcode.img通过。StarryOS 进入 root@starry 后执行 jcode --version，输出 jcode v0.12.0 (unknown)，随后匹配到 STARRY_JCODE_SMOKE_PASSED。
另外也验证了：
PATH="$PWD/target/host-tools/patchelf/usr/bin:$PATH" \
cargo xtask starry app run -t jcode --arch x86_64当前不会再失败在 overlay 注入阶段，但 QEMU 启动后会 panic 于 failed to determine root device from available block devices。对已有的 apps/starry/git 执行同样的 cargo xtask starry app run -t git --arch x86_64 也能复现相同 panic；而 README 中的 starry qemu --rootfs ... 路径会带上 virtio block/net driver 特性并可正常运行。因此这里判断为现有 x86_64 app-run 基线/配置问题，不是本 PR 新增 jcode 资产、rootfs 注入或 smoke 配置引入的阻塞问题。
结论：当前 PR 的 jcode rootfs 准备和离线 QEMU smoke 已实际跑通，未发现 #988 本身的阻塞问题。
2 participants
Add an operator-facing jcode (AI coding agent) workflow under apps/starry/jcode/. The two-stage pipeline downloads jcode from GitHub releases, patches the glibc binary for musl via patchelf + qemu-user, builds a glibc stub .so, and injects everything into a dedicated rootfs image.