HomeAgent

jianf/HomeAgent

Fork 0

mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-10-04 00:03:59 +00:00

Commit Graph

Author	SHA1	Message	Date
JianFeeeee	d7df1dd1c9	build(csrc): C 基础设施门禁（ABI 版本 / 告警 / sanitizer / 交叉编译 / 模糊测试） C 化从「一把刀」推进到「可持续推进」，本轮先把基础设施建起来：不建它，后续每个 C 切片都在裸奔（无告警门禁、无内存安全检查、无交叉编译验证、无 ABI 漂移检测）。新增门禁（make check-csrc / check-csrc-full，已接进 make test）： - csrc-lint gcc+clang 双编译器 × -Wall -Wextra -Wpedantic -Wshadow -Wconversion，零告警才算过（-Wconversion 是为 cgo 窄化准备的：size_t→int 截断在默认档下是静默的） - csrc-abi ABI 版本运行期自述 + 荒谬值检查 - csrc-headers 头文件自包含性（每个 .h 能单独编过） - csrc-sanitize ASan+UBSan 跑 C 契约测试 - csrc-cross arm64 交叉编译（homed 的真实发布目标） - csrc-fuzz libFuzzer：内存安全 + 6 条不变式（可 CI 门禁）新增 ABI 契约（csrc/include/ha_abi.h）： - ha_codec.h 声明「签名冻结」，但冻结只写在注释里；现改为 HA_CODEC_ABI_MAJOR/MINOR + 运行期自述 + Go 侧常量，三方交叉断言，版本漂移在测试期判红而非线上表现为行为诡异。 - 门禁当场抓出我自己的两个真 bug：①_Static_assert 是 C11 而项目是 -std=c99（-Wpedantic 报的）；②##msg 不能拼接字符串字面量，导致两个断言共用一个 typedef 名（clang 报的）。基础设施当场抓出的三个真实缺陷（都是「本机 gcc 能编过、别处会炸」类）： - bench 用了 POSIX clock_gettime，而 CMake 刻意 C_EXTENSIONS OFF （严格 c99）→ 头文件未声明；补 _POSIX_C_SOURCE（须在任何头之前） - 头文件缺 include 时只在「恰好被别的头先包含」处静默编过 - Go 不允许在 _test.go 用 cgo ⇒ C 侧 const 桥接只能放非测试文件，且 cgo 生成的 _Cvar_ 不是 Go 常量（「两边一起错成一样」的盲区，改用 C 函数返回 + 编译期 _Static_assert 补上）实测（全部当场可复现）： - 双编译器 × c99/c11 零告警；ASan+UBSan PASS - libFuzzer 91s 跑 3329316 次、零崩溃（6 条不变式全过） - 变异测试：改 C 侧宏 / 让 Go 常量与 C 函数「一起错成一样」，均被对应断言抓住（证明门禁不是摆设） - C 侧纯函数基准（首次把函数体成本与 cgo 边界成本分开测）： ascii_1k 121.7ns/8.4GB/s；zh_1k 1434ns；truncate 两者均约 128-134ns - 全量 go test -count=1 ./...：57 包 0 FAIL - make build-linux-arm64 → ELF aarch64 - 纪律检查 FAIL=0；SDK 公开接口 diff = 0 行未动：csrc/ 是内核 C ABI，不属 third_party/homeagent-sdk 公开接口。	2026-09-26 09:44:17 +08:00
JianFeeeee	e3867b3481	feat(c-core): 内核编解码层 C 化第一刀 —— L1 纯函数层落地并打通构建链第一刀只做三个纯函数（窗口推断 / token 估算 / token 截断），价值不在功能（Go 版没问题），而在打通「Go → cgo → C」全链路并建立可复现的对照范式，后面每扩一个函数都复用它。 ## 为什么是这三个按「无状态 → 有状态」分层，L1 协议编解码最安全：纯 string in → struct out，不碰网络、不碰 Lua、不碰 goroutine。三个函数更是同一组纯算术，最小可验证切片。 ## 关键设计：包内符号链接，不链接静态库、不 include 包外源三种做法都实测过，只有一种同时满足「可构建 + 可交叉编译 + 缓存可跟踪」： 1. ❌ 链接 `csrc/build/libha_codec.a`（原方案） - .a 是构建产物、不入库（.gitignore 的 build/ 命中 csrc/build/），而发布脚本原先并不产出它 ⇒「不入库 + 不生成」两头空，实测报 `cannot find .../libha_codec.a` - 交叉编译 linux/arm64（homed 真实发布目标）时，宿主 x86-64 的 .a 被链进目标产物，实测报 `file in wrong format` 2. ❌ `#include "../../../csrc/src/ha_codec.c"`（包外相对包含） ★ Go 构建缓存不跟踪包外被 #include 的 C 文件。实测：包外源把返回值 7→8，`go test` 依然通过（缓存命中、静默沿用旧代码）；同样改动落在包内文件时立即判红。对「逐步推进 C 化」这是致命的——改 C 源码不生效且无报错。（包内 shim `#include` 包外源同样漏跟踪，已实测排除。） 3. ✅ 包内符号链接 `internal/agent/api/ha_codec.{c,h}` → `csrc/` 文件在包目录内 ⇒ 缓存按内容正确跟踪；只有一份权威源 ⇒ 无副本漂移，也不需要「同步 C 源」的 make 目标。 ## 不需要额外 build tag ha_codec 是零依赖纯 C99 源码内联编译，不需要外部库或工具链前提；而 homed 本就强制 cgo（sqlite3 + gojieba），故 C 路径自然生效。只用 `cgo` / `!cgo` 一组约束（对比 onnxruntime：那个需运行期 .so，故必须显式 tag）。 ## 顺带修掉的既有缺陷（非 C 化引入，但一直缺覆盖） - Makefile 的 arm64 目标缺 CC/CXX：cgo 回退到宿主 g++，报 `gcc_arm64.S: no such instruction: 'stp x29,x30,[sp,'` （deploy/packaging/build.sh:49 一直是对的，Makefile 漏了） - Makefile 的 arm64 目标缺 .syso 隔离：cmd/{homed,waiter}/.syso 是 Windows COFF 资源对象，Go 会把同目录 .syso 无条件链进任何目标，交叉到非 Windows 平台报 `file format not recognized`（build.sh 有 hide_syso_for_target） ## 验证（每条可复现） - `make build-linux-arm64` → ELF 64-bit LSB executable, ARM aarch64（82MB） - `bash deploy/packaging/build.sh linux/arm64 homed` → ELF aarch64（79MB） - 移走 csrc/build/ 后 homed（cgo）与 waiter（CGO=0）均能构建 - 变异 C 源（131072→777）后同一缓存*下 go test 立即 FAIL（改前：仍报 ok） - `make check-codec-paths` 两条路径 OK；`make csrc-test` C 契约测试 100% - 黄金对照：手写用例 + 2000 次随机对拍，C 与纯 Go 逐值相等 - 全量 `go test -count=1 ./...` → 57 包：38 ok + 19 无测试 + 0 FAIL 新增 `make check-codec-paths` 防回归：只测一条路径时，另一条的破坏不会被发现。 ## 文档 - `docs/zh/c-core/llm-orchestration-c.md` 同步为「已落地」，并更正因「Windows 原生已放弃」而过时的 §2.3（回退路径的理由需重述） - plan.md 的 P0-1 标记为已修复，附实测证据	2026-09-25 14:45:08 +08:00

Author

SHA1

Message

Date

JianFeeeee

d7df1dd1c9

build(csrc): C 基础设施门禁（ABI 版本 / 告警 / sanitizer / 交叉编译 / 模糊测试）

C 化从「一把刀」推进到「可持续推进」，本轮先把基础设施建起来：
不建它，后续每个 C 切片都在裸奔（无告警门禁、无内存安全检查、
无交叉编译验证、无 ABI 漂移检测）。

新增门禁（make check-csrc / check-csrc-full，已接进 make test）：
- csrc-lint   gcc+clang 双编译器 × -Wall -Wextra -Wpedantic -Wshadow
              -Wconversion，零告警才算过（-Wconversion 是为 cgo 窄化
              准备的：size_t→int 截断在默认档下是静默的）
- csrc-abi    ABI 版本运行期自述 + 荒谬值检查
- csrc-headers 头文件自包含性（每个 .h 能单独编过）
- csrc-sanitize ASan+UBSan 跑 C 契约测试
- csrc-cross  arm64 交叉编译（homed 的真实发布目标）
- csrc-fuzz   libFuzzer：内存安全 + 6 条不变式（可 CI 门禁）

新增 ABI 契约（csrc/include/ha_abi.h）：
- ha_codec.h 声明「签名冻结」，但冻结只写在注释里；现改为
  HA_CODEC_ABI_MAJOR/MINOR + 运行期自述 + Go 侧常量，
  三方交叉断言，版本漂移在测试期判红而非线上表现为行为诡异。
- 门禁当场抓出我自己的两个真 bug：①_Static_assert 是 C11 而项目
  是 -std=c99（-Wpedantic 报的）；②##msg 不能拼接字符串字面量，
  导致两个断言共用一个 typedef 名（clang 报的）。

基础设施当场抓出的三个真实缺陷（都是「本机 gcc 能编过、别处会炸」类）：
- bench 用了 POSIX clock_gettime，而 CMake 刻意 C_EXTENSIONS OFF
  （严格 c99）→ 头文件未声明；补 _POSIX_C_SOURCE（须在任何头之前）
- 头文件缺 include 时只在「恰好被别的头先包含」处静默编过
- Go 不允许在 _test.go 用 cgo ⇒ C 侧 const 桥接只能放非测试文件，
  且 cgo 生成的 *_Cvar_* 不是 Go 常量（「两边一起错成一样」的盲区，
  改用 C 函数返回 + 编译期 _Static_assert 补上）

实测（全部当场可复现）：
- 双编译器 × c99/c11 零告警；ASan+UBSan PASS
- libFuzzer 91s 跑 3329316 次、零崩溃（6 条不变式全过）
- 变异测试：改 C 侧宏 / 让 Go 常量与 C 函数「一起错成一样」，
  均被对应断言抓住（证明门禁不是摆设）
- C 侧纯函数基准（首次把函数体成本与 cgo 边界成本分开测）：
  ascii_1k 121.7ns/8.4GB/s；zh_1k 1434ns；truncate 两者均约 128-134ns
- 全量 go test -count=1 ./...：57 包 0 FAIL
- make build-linux-arm64 → ELF aarch64
- 纪律检查 FAIL=0；SDK 公开接口 diff = 0 行

未动：csrc/ 是内核 C ABI，不属 third_party/homeagent-sdk 公开接口。

2026-09-26 09:44:17 +08:00

JianFeeeee

e3867b3481

feat(c-core): 内核编解码层 C 化第一刀 —— L1 纯函数层落地并打通构建链

第一刀只做三个纯函数（窗口推断 / token 估算 / token 截断），
价值不在功能（Go 版没问题），而在打通「Go → cgo → C」全链路并
建立可复现的对照范式，后面每扩一个函数都复用它。

## 为什么是这三个

按「无状态 → 有状态」分层，L1 协议编解码最安全：纯 string in → struct out，
不碰网络、不碰 Lua、不碰 goroutine。三个函数更是同一组纯算术，最小可验证切片。

## 关键设计：包内符号链接，不链接静态库、不 include 包外源

三种做法都实测过，只有一种同时满足「可构建 + 可交叉编译 + 缓存可跟踪」：

1. ❌ 链接 `csrc/build/libha_codec.a`（原方案）
   - .a 是构建产物、不入库（.gitignore 的 build/ 命中 csrc/build/），
     而发布脚本原先并不产出它 ⇒「不入库 + 不生成」两头空，
     实测报 `cannot find .../libha_codec.a`
   - 交叉编译 linux/arm64（homed 真实发布目标）时，宿主 x86-64 的 .a
     被链进目标产物，实测报 `file in wrong format`

2. ❌ `#include "../../../csrc/src/ha_codec.c"`（包外相对包含）
   ★ Go 构建缓存**不跟踪包外被 #include 的 C 文件**。实测：包外源把返回值
   7→8，`go test` 依然通过（缓存命中、静默沿用旧代码）；同样改动落在包内
   文件时立即判红。对「逐步推进 C 化」这是致命的——改 C 源码不生效且无报错。
   （包内 shim `#include` 包外源同样漏跟踪，已实测排除。）

3. ✅ 包内符号链接 `internal/agent/api/ha_codec.{c,h}` → `csrc/`
   文件在包目录内 ⇒ 缓存按内容正确跟踪；只有一份权威源 ⇒ 无副本漂移，
   也不需要「同步 C 源」的 make 目标。

## 不需要额外 build tag

ha_codec 是零依赖纯 C99 源码内联编译，不需要外部库或工具链前提；
而 homed 本就强制 cgo（sqlite3 + gojieba），故 C 路径自然生效。
只用 `cgo` / `!cgo` 一组约束（对比 onnxruntime：那个需运行期 .so，故必须显式 tag）。

## 顺带修掉的既有缺陷（非 C 化引入，但一直缺覆盖）

- Makefile 的 arm64 目标缺 CC/CXX：cgo 回退到宿主 g++，报
  `gcc_arm64.S: no such instruction: 'stp x29,x30,[sp,'`
  （deploy/packaging/build.sh:49 一直是对的，Makefile 漏了）
- Makefile 的 arm64 目标缺 .syso 隔离：cmd/{homed,waiter}/*.syso 是 Windows
  COFF 资源对象，Go 会把同目录 .syso 无条件链进任何目标，交叉到非 Windows
  平台报 `file format not recognized`（build.sh 有 hide_syso_for_target）

## 验证（每条可复现）

- `make build-linux-arm64` → ELF 64-bit LSB executable, ARM aarch64（82MB）
- `bash deploy/packaging/build.sh linux/arm64 homed` → ELF aarch64（79MB）
- 移走 csrc/build/ 后 homed（cgo）与 waiter（CGO=0）均能构建
- 变异 C 源（131072→777）后**同一缓存**下 go test 立即 FAIL（改前：仍报 ok）
- `make check-codec-paths` 两条路径 OK；`make csrc-test` C 契约测试 100%
- 黄金对照：手写用例 + 2000 次随机对拍，C 与纯 Go 逐值相等
- 全量 `go test -count=1 ./...` → 57 包：38 ok + 19 无测试 + 0 FAIL

新增 `make check-codec-paths` 防回归：只测一条路径时，另一条的破坏不会被发现。

## 文档

- `docs/zh/c-core/llm-orchestration-c.md` 同步为「已落地」，并更正因
  「Windows 原生已放弃」而过时的 §2.3（回退路径的理由需重述）
- plan.md 的 P0-1 标记为已修复，附实测证据

2026-09-25 14:45:08 +08:00

2 Commits