revert(freestanding): drop dead-section elimination from this change

⚠️ MEASURED TO BREAK A JOB THAT IS GREEN ON main, BY A MECHANISM THAT
CONTRADICTS THE CODE, WHICH IS REASON ENOUGH NOT TO SHIP IT.

`--gc-sections` was correct on this machine and in the bare-metal CI job. It
broke the openkal cross-build on a WINDOWS host:

    lld: error: unable to find library -lntdll        (and four more)

Three-way control, not reasoning:

    main, via workflow_dispatch                       build 3 targets on windows  ✅
    this PR, with gc-sections (three runs)                                        ❌
    bisect/no-gc-sections, that change alone reverted                             ✅

And the result contradicts the model. Both call sites sit inside
`isFreestandingTarget`, which `x86_64-windows-gnu` does not satisfy; the same
cross-build succeeds on a Linux host; and the `-Wl,--gc-sections` visible in the
failing link line was traced to openkal-windows' own manifest rather than to the
engine. The actual symptom is a MISSING `-L` for the directory holding the
import libraries that package generates.

So the mechanism is not understood, and an unexplained change does not belong in
a release. The flags are removed here and the finding is recorded in
`.agents/docs/2026-09-04-…-plan.md` §10.1 with the control that establishes it,
because dead-section elimination remains a prerequisite for a C library supplied
from the dependency graph.

The Cortex-M rows do not depend on it: they build, link and boot without it, and
the e2e still asserts the vector table is present and the float ABI is honoured
on both sides. Only the two dead-code assertions are withdrawn.

Author: speak-agent

.agents/docs/2026-09-04-commercial-grade-baremetal-embedded-plan.md

@@ -436,10 +436,39 @@ v1 按工程依赖把 E 整个排到 P2。自审:**其中一半没有工程依
 | 条目 | 状态 |
 |---|---|
 | Cortex-M 目标行 | ✅ **七行**,`kKnownTargets` 与 `freestanding::kTable` 各七行 |
-| D11 死代码段消除 | ✅ `-ffunction-sections -fdata-sections` + `--gc-sections`(驱动路径与直接 lld 路径) |
+| D11 死代码段消除 | ❌ **撤出本 PR** —— 实测打断 Windows 宿主上的 openkal 交叉构建,见 §10.1 |
 | `docs/13` 回填两条失效限制 | ✅ 中英双份 |
 | 判据 | ✅ e2e 332(四行在 QEMU 中启动)+ 三条单测;CI `bare-metal e2e` 作业已绿 |
 
+### ⚠️⚠️ 10.1 D11 被实测挡住,而挡住它的机制尚未查清
+
+`--gc-sections` 在本机(Linux 宿主)与 CI 的裸机作业上都正确;它打断的是
+**openkal 在 Windows 宿主上的交叉构建**:
+
+```
+lld: error: unable to find library -lntdll
+lld: error: unable to find library -lkernel32   (等五条)
+```
+
+判据是三次对照,不是推理:
+
+| 分支 | `build 3 targets on windows` |
+|---|---|
+| `main`(workflow_dispatch 对照) | ✅ |
+| 本 PR(含 gc-sections,三次) | ❌ |
+| `bisect/no-gc-sections`(只去掉 gc-sections) | ✅ |
+
+⚠️ **而这条与我的机制模型矛盾**:两处 `gc-sections` 都在 `isFreestandingTarget`
+之内,`x86_64-windows-gnu` 不该进那个分支;本机 Linux→Windows 交叉**能成功**,且
+失败的链接行里的 `-Wl,--gc-sections` 经核对来自 **openkal-windows 自己的清单**
+而不是引擎。失败的真正现象是链接行**缺了 `-L<openkal-windows 的 out 目录>`** ——
+那个目录里正是它生成的 `libntdll.a` 等导入库。
+
+⇒ **测量胜过模型**:一个我解释不了的改动不该合入。D11 退回待办,并带上这条判据 ——
+它同时是「图来源 C 库」那条路线必须先解决的前置。⭐ 附带发现:openkal 的包**已经
+在自己的清单里用 `-ffunction-sections` 与 `-Wl,--gc-sections`**,所以引擎侧是否
+需要再发一份,本身也要重新论证。
+
 ### ⚠️ 实施推翻的两处方案原文
 
 **① `extra` 列不承载浮点 ABI —— triple 已经承载了它。**
@@ -464,6 +493,8 @@ clang 对一次 float 乘法仍发出 `vmul.f32` —— 在没有 FPU 的 Cortex
 
 ### 未实施(按方案原顺序)
 
+**D11 死代码段消除**(见 §10.1,已从本 PR 撤出,带判据)·
+
 `P0` 的 `mcpplibs/picolibc` + `compiler-rt-builtins` 源码包(§3.1.1)· 板级包三个 ·
 `P0'` 的 `xim:probe-rs` 与 E 轴零工程项 · `P1`/`P1'` 真机 · `P1'` 槽表 ·
 `P2` lock 成钉与 SBOM · `P3` openarch 第四后端 · `P3'` 嵌入式 Linux。

CHANGELOG.md

@@ -5,7 +5,7 @@
 
 ## [2026.9.4.1] — 2026-09-04
 
-Cortex-M 落地为七个目标行,freestanding 链接开启死代码段消除。
+Cortex-M 落地为七个目标行。
 
 裸机目标表从四行增至十一行。M-profile 是七行而不是一行:为 `thumbv7em` 构建的
 目标文件使用 Cortex-M0 没有的指令,两种拼写产出互不兼容的目标文件,而表存在的
@@ -23,13 +23,6 @@ target = "thumbv7em-none-eabihf"
 因此携带 `-mfpu=none`,包括架构本来就没有 FPU 的那几行 —— 一行陈述它保证的性质,
 而不是从一个可以改变的默认值继承它。
 
-freestanding 编译加 `-ffunction-sections -fdata-sections`、链接加 `--gc-sections`。
-依赖的目标文件无条件进入链接(不像归档成员那样按未定义符号拉取),当 C 库改由
-依赖图提供时,没有死代码段消除的镜像会装进整份 C 库,而 Cortex-M 器件只有几十 KB。
-
-⚠️ **链接脚本因此以新的方式承重**:中断向量表不被任何东西引用,`--gc-sections`
-会回收它,板级脚本必须写 `KEEP(*(.vectors))`。
-
 同时回填了 `docs/13` 中两条已被 2026.8.28.2 推翻的限制:当图中有包提供
 `hosted-standard-library` 时,裸机目标上的异常、RTTI 与 `import std` 均可用。
 

docs/13-baremetal.md

@@ -59,95 +59,6 @@ Cortex-M needs no `lldEmulation` column entry: clang has a *BareMetal* toolchain
 for arm, so these triples reach `ld.lld` through the driver as the RISC-V and
 aarch64 rows do. 32-bit ARM has no `-mcmodel` axis, so that column is empty too.
 
-### Dead-section elimination
-
-Freestanding builds compile with `-ffunction-sections -fdata-sections` and link
-with `--gc-sections`. Both halves belong to the engine rather than to a project
-because a dependency's translation units must carry them, and a project cannot
-reach those.
-
-The flags became necessary rather than merely economical when a C library began
-arriving from the dependency graph. A dependency's object files enter the link
-unconditionally, unlike an archive member, which is pulled only while its symbol
-is undefined. That costs nothing when the C library is a prebuilt archive and
-the target has megabytes; a Cortex-M part has kilobytes, and without dead-section
-elimination every image would carry the whole of the C library.
-
-⚠️ **A linker script becomes load-bearing in a new way.** An interrupt vector
-table is referenced by nothing — the hardware reads it by address — so
-`--gc-sections` collects it. A board's script must say `KEEP(*(.vectors))`.
-Measured: with the `KEEP` present, a function nothing calls is dropped, the
-table survives, and the image boots.
-
-⚠️ The last two rows default to no C library, and that is a statement rather
-than an omission: the first consumer of both rows — the `openarch` layer of
-machine mechanism — references no C library symbol, and if no row defaulted to
-this tier there would be nothing demonstrating the tier works.
-⭐ **A build for those rows is declarable, not absent** (mcpp 2026.8.21.3+).
-`xim:picolibc-aarch64` and `xim:picolibc-x86` are in the index; a project that
-wants one names it the same way it would choose a different one:
-
-```toml
-[target.aarch64-none-elf]
-sysroot = "xim:picolibc-aarch64@1.8.12"
-``` An empty column means exactly what
-`[target.<triple>].sysroot = ""` means in a manifest, so a project targeting one
-begins on the zero-libc tier without asking. A project that wants a C library on
-those targets declares one, which is also how it would choose a different one.
-
-Such a target needs no per-host cross toolchain. clang and lld are
-cross-compilers by construction — one binary emits every target it was built
-with — so the target table pins `llvm@22.1.8` on every host, and any machine
-that can install the LLVM payload can produce an image for any of the four.
-
-### The x86_64 row is not four strings
-
-⚠️ **A target row is normally an entry in two tables and nothing else. This one
-needed engine code, and the reason is a property of clang rather than of the
-instruction set.**
-
-clang selects a toolchain from the triple. It has a *BareMetal* toolchain for
-arm, aarch64 and riscv, which links with `ld.lld` directly; it has none for
-x86_64, so every spelling of a bare x86_64 triple falls through to the generic
-GCC toolchain — whose linker is the **host's `g++`**:
-
-```
-g++: error: unrecognized command-line option '-fuse-ld=/…/llvm/22.1.8/bin/ld.lld'
-```
-
-Measured for `x86_64-none-elf`, `x86_64-unknown-none-elf`, `x86_64-unknown-none`,
-`x86_64-elf`, `x86_64-none-none` and `x86_64-unknown-unknown`, and unchanged by
-`-fuse-ld=lld`, `--ld-path=`, `--gcc-toolchain=` or `-B`. The one thing that
-does change it is putting `linux` in the OS position, which makes clang link
-directly and adds eight host `-L` paths to a bare-metal link.
-
-Neither outcome is acceptable: routing through a host `g++` makes the row work
-on a Linux host and nowhere else, and host search paths on a freestanding link
-are the hermeticity this engine exists to keep. So the row carries a fifth
-column, `lldEmulation`, and when it is set the engine drives the link with
-`ld.lld` itself. The flag vocabulary changes with the tool — `-Map=` rather than
-`-Wl,-Map=`, `-m elf_x86_64` rather than `--target=` — and the driver-only flags
-(`-nostdlib++`, the loader tag) are dropped rather than translated.
-
-The column is empty for the riscv and aarch64 rows. Their driver already reaches
-lld, and changing a working link to make three rows look alike is how a
-regression is introduced.
-
-### `-mno-red-zone` is part of the target, not a preference
-
-The System V x86-64 ABI reserves 128 bytes below `rsp` that a leaf function may
-use without adjusting the stack pointer, because on a hosted system nothing else
-writes there. On bare metal the processor pushes an interrupt frame at `rsp` —
-into the red zone — and the interrupted leaf resumes to find its locals
-overwritten. There is no fault and no diagnostic, and it happens only when an
-interrupt arrives inside a leaf.
-
-There is no bare-metal x86_64 program for which the red zone is safe, so the
-flag is a property of the row rather than something a project remembers. It
-reaches the command line through a new `extra` column in the ISA-profile table,
-which exists because `-march`/`-mabi`/`-mcmodel` could not express it. RISC-V
-and aarch64 have no equivalent, which is why the column did not exist before.
-
 Three things a bare-metal build requires are not properties of the ISA, and
 mcpp does not attempt to derive them: which startup object and libraries to
 select, which linker script describes the machine's memory, and how to execute

docs/zh/13-baremetal.md

@@ -52,82 +52,6 @@ Cortex-M 不需要 `lldEmulation` 列:clang 有面向 arm 的 *BareMetal* 工具
 triple 与 RISC-V、aarch64 各行一样经驱动到达 `ld.lld`。32 位 ARM 没有 `-mcmodel`
 这个轴,所以该列同样为空。
 
-### 死代码段消除
-
-freestanding 构建以 `-ffunction-sections -fdata-sections` 编译,以 `--gc-sections`
-链接。两半都属于引擎而不属于工程,因为依赖的翻译单元也必须带上它们,而工程够不到
-那些单元。
-
-这两个标志从「划算」变成「必需」,发生在 C 库开始由依赖图提供的时候。依赖的目标
-文件是**无条件**进入链接的,不像归档成员那样只在符号仍未定义时才被拉入。当 C 库是
-预编译归档、目标又有若干兆字节时,这不花什么代价;而 Cortex-M 器件只有几十 KB,
-没有死代码段消除,每个镜像都会装进整份 C 库。
-
-⚠️ **链接脚本因此以一种新的方式承重。** 中断向量表不被任何东西引用 —— 硬件按地址
-读取它 —— 所以 `--gc-sections` 会把它回收。板级脚本必须写 `KEEP(*(.vectors))`。
-实测:有这条 `KEEP` 时,无人调用的函数被丢弃、向量表被保留、镜像能够启动。
-
-⚠️ 后两行**默认**没有 C 库,这是声明而非遗漏:这两行的第一个消费者 —— 机器机制层
-`openarch` —— 一个 C 库符号都不引用,而**如果四行里没有一行默认在这一层,就没有
-任何东西在证明这一层可用**。空列在这里的含义与清单里
-`[target.<triple>].sysroot = ""` 完全一致。
-
-⭐ **这两行的 C 库是可声明的,不是不存在的**(mcpp 2026.8.21.3+)。
-`xim:picolibc-aarch64` 与 `xim:picolibc-x86` 已在索引里;想要它的工程自行声明,
-而那与它换用另一份 C 库是同一个动作:
-
-```toml
-[target.aarch64-none-elf]
-sysroot = "xim:picolibc-aarch64@1.8.12"
-```
-
-这类目标不需要逐宿主的交叉工具链。clang 与 lld 在构造上就是交叉编译器 ——
-一个二进制发射它构建时支持的全部目标 —— 因此目标表在每个宿主上都钉
-`llvm@22.1.8`,任何能安装 LLVM 载荷的机器都能为这四个中的任何一个产出镜像。
-
-### x86_64 这一行不止是四个字符串
-
-⚠️ **一个目标行通常就是两张表里的两条记录,不含引擎代码。这一行需要引擎代码,
-而原因是 clang 的属性而非指令集的属性。**
-
-clang 由 triple 选择工具链。它为 arm、aarch64、riscv 备有 *BareMetal* 工具链,
-直接以 `ld.lld` 链接;它没有 x86_64 的,于是裸 x86_64 triple 的每一种写法都落到
-通用 GCC 工具链上 —— 而后者的链接器是**宿主的 `g++`**:
-
-```
-g++: error: unrecognized command-line option '-fuse-ld=/…/llvm/22.1.8/bin/ld.lld'
-```
-
-对 `x86_64-none-elf`、`x86_64-unknown-none-elf`、`x86_64-unknown-none`、
-`x86_64-elf`、`x86_64-none-none`、`x86_64-unknown-unknown` 逐一实测,结果一致;
-`-fuse-ld=lld`、`--ld-path=`、`--gcc-toolchain=`、`-B` 逐一实测,均不改变结果。
-唯一能改变它的是把 `linux` 放进 OS 位,而那会给一次裸机链接带来八条宿主 `-L`。
-
-两种结果都不可接受:经宿主 `g++` 会让这一行只在 Linux 宿主上成立;宿主搜索路径
-出现在 freestanding 链接上,正是本引擎存在的意义所要守住的封闭性。因此该行带了
-第五列 `lldEmulation`,置位时引擎直接用 `ld.lld` 驱动链接。标志的词汇随工具一同
-改变 —— `-Map=` 而非 `-Wl,-Map=`,`-m elf_x86_64` 而非 `--target=` —— 而仅属于
-驱动的标志(`-nostdlib++`、加载器标签)是被丢弃而不是被翻译。
-
-riscv 与 aarch64 两行的该列为空。它们的驱动本就到得了 lld,为了让三行看起来一致
-而改动一条可用的链接,正是引入回归的方式。
-
-### `-mno-red-zone` 是目标的属性,不是偏好
-
-System V x86-64 ABI 在 `rsp` 之下保留 128 字节,叶函数可以不调整栈指针直接使用,
-因为在有操作系统的机器上没有别的东西会写那里。裸机上不存在做这件事的一方:处理器
-在 `rsp` 处压入中断帧 —— 正压进红区 —— 被中断的叶函数恢复后发现自己的局部变量已被
-覆盖。既不触发异常也没有诊断,而且只在中断恰好落在叶函数内部时发生。
-
-不存在红区安全的裸机 x86_64 程序,所以这个标志是行的属性,而不是工程需要记住的
-事情。它经 ISA 档表新增的 `extra` 列到达命令行 —— 该列之所以存在,是因为
-`-march`/`-mabi`/`-mcmodel` 表达不了它。RISC-V 与 aarch64 没有对应物,这也正是
-此前不需要这一列的原因。
-
-裸机构建需要的三样东西并不是 ISA 的属性,mcpp 也不试图推导它们:选哪个启动对象
-与哪些库、哪份链接脚本描述这台机器的内存、以及如何执行产出的镜像。这三样随
-**板级支持包**一起提供,而板级支持包是一个普通依赖。由此得到的结果是:换板子是
-一次依赖变更,而不是一次构建系统变更。
 
 ## 从零到一个可运行的镜像
 

src/freestanding/linkline.cppm

@@ -89,9 +89,6 @@ inline std::string link_flags(const Spec& s, const LinkInputs& in,
     // suggesting it does.
     for (auto const& f : compile_flags(s)) { out += ' '; out += f; }
     out += " -nostdlib -nostartfiles -static";
-    // The link half of the pair set in mcpp.freestanding.target's
-    // `compile_flags`. Routed through the driver, hence `-Wl,`.
-    out += " -Wl,--gc-sections";
     if (!in.lld.empty())
         out += " -fuse-ld=" + esc(in.lld);
     // ⚠️ BEFORE the libraries the board selects, and it has to be on THIS line
@@ -132,11 +129,6 @@ inline std::string link_flags_direct(const Spec& s, const LinkInputs& in,
     // No loader exists, so an image must not name one. The driver line reaches
     // this through `-static`; here it is said to the linker.
     out += " --no-dynamic-linker";
-    // Said to the linker directly here, as `-Wl,--gc-sections` is said through
-    // the driver on the line above. The two paths must agree: a target whose
-    // link is driven by `ld.lld` itself would otherwise keep every section its
-    // dependencies emit, and the difference would show only as size.
-    out += " --gc-sections";
     if (!in.sysrootLib.empty())
         out += " -L" + esc(in.sysrootLib);
     if (!in.linkerScript.empty())

src/freestanding/target.cppm

@@ -291,30 +291,6 @@ inline std::vector<std::string> compile_flags(const Spec& s,
     // `-ffreestanding` so the ordering of this function's output stays a
     // function of the table rather than of the row.
     for (auto flag : s.extra) out.emplace_back(flag);
-    // ⭐⭐ ONE SECTION PER FUNCTION, SO THE LINKER CAN DROP WHAT NOTHING CALLS.
-    //
-    // These two flags do nothing on their own; they are the half of
-    // `--gc-sections` that has to happen at compile time, and the link half is
-    // in mcpp.freestanding.linkline. Both halves are here rather than left to a
-    // project because a dependency's translation units must carry them too, and
-    // a project cannot reach those.
-    //
-    // ⚠️ WHY THIS BECAME NECESSARY RATHER THAN MERELY NICE. A dependency's
-    // object files enter the link unconditionally (docs/13), unlike an archive
-    // member, which is pulled only while its symbol is undefined. That costs
-    // nothing when the C library is a prebuilt archive and the target has
-    // megabytes — the arrangement every bare-metal row had until now. A C
-    // library that arrives from the dependency graph is object files, and a
-    // Cortex-M part has kilobytes: without this, every image carries the whole
-    // of the C library whether or not it calls into it.
-    //
-    // ⚠️ AND IT MAKES A LINKER SCRIPT LOAD-BEARING IN A NEW WAY: an interrupt
-    // vector table is referenced by nothing — the hardware reads it by address
-    // — so `--gc-sections` collects it. A board's script must say
-    // `KEEP(*(.vectors))`. Measured: with the KEEP present, a dead function is
-    // dropped and the table survives; the image boots.
-    out.emplace_back("-ffunction-sections");
-    out.emplace_back("-fdata-sections");
     // ⭐ AND `-ffreestanding` ITSELF IS ONE OF THE THINGS THE GRAPH DECIDES.
     //
     // The paragraph above this function names what the flag changes: "no `main`