The toolchain builds clang and ld.lld for x86_64-unknown-toyos, statically linked; libc gains what they link

issues/a-childs-end-is-an-event-and-a-parent-takes-its-children-down.md

@@ -6,8 +6,8 @@ opened: 2026-09-29
 
 # A child's end is an event, and a parent takes its children down
 
-libc cannot start a child: `fork` and `execvp` answer `ENOSYS`, `waitpid`
-`ECHILD` and `system` `-1` (`userland/libc/src/misc.rs`,
+libc cannot start a child: `fork` and `execvp` answer `ENOSYS`, `waitpid`,
+`wait` and `wait4` `ECHILD`, and `system` `-1` (`userland/libc/src/misc.rs`,
 `userland/libc/src/stdio.rs`), and there is no `posix_spawn`. M2 and M4 of
 `issues/toyos-builds-itself.md` and the exit of
 `issues/toyos-runs-on-arm64.md` need it.

issues/a-shared-object-does-not-link-against-the-c-sysroot-with-z-defs.md

@@ -9,12 +9,12 @@ opened: 2026-10-01
 ToyOS loads shared objects, a program's `DT_NEEDED` and `dlopen`'s, and its
 clang links one with `-shared`. None links against the C sysroot with
 `-z defs`. A C one linked without it leaves `__tls_get_addr` undefined, and
-lld refuses the executable that links it for that name. LLVM built for
-`x86_64-unknown-toyos`
-(`issues/bootstrap-cannot-build-llvm-clang-and-lld-for-a-toyos-host.md`)
-builds `libLTO`, `libRemarks`, `libclang` and `libclang-cpp`, linked
-`-shared -z defs`, and each stops on what the sysroot's archives were built
-for, an executable:
+lld refuses the executable that links it for that name. LLVM built whole for
+`x86_64-unknown-toyos`, as M3's rustc needs it
+(`issues/rustc-llvm-cannot-build-for-a-toyos-host.md`), builds `libLTO`,
+`libRemarks`, `libclang` and `libclang-cpp`, linked `-shared -z defs`, none
+of which the ToyOS-hosted clang and LLD (`src/hostedclang.rs`) need, and
+each stops on what the sysroot's archives were built for, an executable:
 
 - `main`, undefined: `libtoyos_c.a`'s entry point, `start_c`, sits in an
   object the link takes for other names.

issues/a-toyos-hosted-llvm-is-configured-as-running-on-the-build-machine.md

@@ -8,14 +8,16 @@ opened: 2026-10-03
 
 LLVM takes `LLVM_HOST_TRIPLE` from `config.guess`, run by the CMake that
 configures it (`llvm/cmake/modules/GetHostTriple.cmake`,
-`llvm/cmake/config-ix.cmake`), unless the configuration names one, and
-bootstrap names none: the `rust/` fork's
-`src/bootstrap/src/core/build_steps/llvm.rs` defines
-`LLVM_DEFAULT_TARGET_TRIPLE` and no `LLVM_HOST_TRIPLE`. So the LLVM that M2
-cross-builds to run on ToyOS (`issues/toyos-builds-itself.md`) records
-the machine that built it as its host. The configure of that build on the
-development Mac, the fork at the commit `main` pins (`95960d6c214`), logged
-(#682, comment 5968053849)
+`llvm/cmake/config-ix.cmake`), unless the configuration names one. The
+ToyOS-hosted clang and LLD name it (`src/hostedclang.rs`), and their
+configure logs `LLVM host triple: x86_64-unknown-toyos`. Bootstrap names none:
+the `rust/` fork's `src/bootstrap/src/core/build_steps/llvm.rs` defines
+`LLVM_DEFAULT_TARGET_TRIPLE` and no `LLVM_HOST_TRIPLE`. So the LLVM that M3's
+rustc carries, built by bootstrap for a ToyOS host
+(`issues/rustc-llvm-cannot-build-for-a-toyos-host.md`), records the machine
+that built it as its host. The configure of that build on the development
+Mac, the fork at the commit `main` pinned then (`95960d6c214`), logged (#682,
+comment 5968053849)
 
 ```
 -- LLVM host triple: arm64-apple-darwin27.0.0
@@ -26,8 +28,8 @@ development Mac, the fork at the commit `main` pins (`95960d6c214`), logged
 it exits non-zero, so a configure run inside ToyOS stops there. That half is
 read from `GetHostTriple.cmake`, not run.
 
-Owner: `issues/toyos-builds-itself.md`: M2 for the triple the host
-build records, M5 for the configure inside ToyOS.
+Owner: `issues/toyos-builds-itself.md`: M3 for the triple bootstrap's build
+records, M5 for the configure inside ToyOS.
 
-Exit condition: the configure of a ToyOS-hosted LLVM logs `LLVM host triple:
-x86_64-unknown-toyos`, and a configure inside ToyOS reaches its end.
+Exit condition: bootstrap's configure of a ToyOS-hosted LLVM logs `LLVM host
+triple: x86_64-unknown-toyos`, and a configure inside ToyOS reaches its end.

issues/an-alarm-reaches-no-sigalrm-handler.md

@@ -0,0 +1,40 @@
+---
+status: open
+kind: defect
+opened: 2026-09-30
+---
+
+# An alarm reaches no SIGALRM handler
+
+libc's `alarm` (`userland/libc/src/alarm.rs`) arms one alarm per process and
+answers the seconds the one it replaces had left, and when it is due a thread
+of libc's drops it if `SIGALRM` is ignored and otherwise ends the process with
+exit code 142, `SIGALRM`'s default action. POSIX keeps the process in two of
+those cases:
+
+- **A handler.** `signal` and `sigaction` keep `SIGALRM`'s disposition, and a
+  handler never runs. LLVM bounds its wait on a child with one: a `SIGALRM`
+  handler makes `wait4` answer `EINTR` (`llvm/lib/Support/Unix/Program.inc`,
+  `Wait`).
+- **A mask.** `SIGALRM` blocked in every thread stays pending until a thread
+  unblocks it, and libc ends the process at once. libc keeps each thread's
+  mask in that thread alone (`userland/libc/src/pthread.rs`, `MASK`), and a
+  thread Rust's std starts is none of libc's, so nothing can read whether
+  every thread blocks it.
+
+POSIX gives `alarm` no refusal, and its `SIGALRM` reaches a handler, or waits
+pending on a mask, only through the signals libc imitates from stage 3 of
+`issues/a-childs-end-is-an-event-and-a-parent-takes-its-children-down.md` on;
+both wait on that stage, its owner.
+
+What a due alarm does under each disposition is held on the host
+(`tests/libc-arch/src/alarm_requests.rs`); `207_libc_names.c` reads the
+action back whole and arms and disarms an alarm. No guest case lets one come
+due.
+
+**Exit**: a guest C case shows `SIGALRM` delivered as POSIX says: a handler
+installed without `SA_RESTART` runs, and a `wait4` on a child that has not
+ended answers `EINTR`; with `SIGALRM` blocked in every thread, a due alarm
+leaves the process running and `sigpending` names it, until an unblock ends
+the process with 142; and with it ignored, a due alarm leaves the process
+running.

issues/bootstrap-cannot-build-llvm-clang-and-lld-for-a-toyos-host.md

@@ -6,32 +6,37 @@ opened: 2026-09-30
 
 # Bootstrap cannot build LLVM, clang and lld for a ToyOS host
 
-M2's clang and lld (`issues/toyos-builds-itself.md`) are bootstrap's
-`Llvm` step, with `clang = true`, and its `Lld` step for
-`x86_64-unknown-toyos`, in a bootstrap build that names no `llvm-config` for
-the build triple and so builds that triple's LLVM, and its `clang-tblgen`,
-itself. CMake takes its toolchain file from
-`CMAKE_TOOLCHAIN_FILE_x86_64_unknown_toyos`: one that includes the C sysroot's
-`toolchain.cmake` and adds the ToyOS LLVM's install to `CMAKE_FIND_ROOT_PATH`,
-because the `Lld` step names that LLVM to `find_package` by a hint, and the
-sysroot's file has CMake find a package under a root alone. What stops the
-build, in the order it stops it:
+The track holds one build of one fork (`issues/toyos-builds-itself.md`), and
+the tree builds LLVM for a ToyOS host by two paths. M2's clang and `ld.lld`
+come from a CMake configure and n2 build of their own (`src/hostedclang.rs`).
+M3's rustc carries an LLVM that bootstrap's `Llvm` step builds for
+`x86_64-unknown-toyos` (`issues/rustc-llvm-cannot-build-for-a-toyos-host.md`),
+and bootstrap's `Llvm` step, with `clang = true`, and its `Lld` step make that
+host's clang and lld too. One LLVM, one host, two code paths.
 
-- **Compile.** The first errors are `Support`'s: `Unix/Watchdog.inc` and
-  `Unix/Program.inc` call `alarm` (`issues/libc-has-no-alarm.md`), and
-  `Program.inc` stage 3's `wait` and `wait4`
-  (`issues/a-childs-end-is-an-event-and-a-parent-takes-its-children-down.md`).
-  Then ORC's `shm_open` and `shm_unlink`, the interpreter's `scanf` and
+Bootstrap's build names no `llvm-config` for the build triple, and so builds
+that triple's LLVM, and its `clang-tblgen`, itself. CMake takes its toolchain
+file from `CMAKE_TOOLCHAIN_FILE_x86_64_unknown_toyos`: one that includes the C
+sysroot's `toolchain.cmake` and adds the ToyOS LLVM's install to
+`CMAKE_FIND_ROOT_PATH`, because the `Lld` step names that LLVM to
+`find_package` by a hint, and the sysroot's file has CMake find a package
+under a root alone. libc and libc++ now give what stopped a CMake build of
+clang and lld from the same commit, measured in #809: `alarm`, `wait`, `wait4`,
+`lround` and `std::filesystem`. Bootstrap's build, which builds all of LLVM,
+has not run since; what is known to stop it besides:
+
+- ORC's `shm_open` and `shm_unlink`, the interpreter's `scanf` and
   `llvm-objdump`'s `ctime`
-  (`issues/libc-lacks-names-llvm-for-a-toyos-host-calls.md`), and
-  clang's `std::ifstream`, which libc++ has only with `std::filesystem`
-  (`issues/libcxx-is-built-without-std-filesystem.md`).
-- **Link.** clang needs `lround`, which libc does not define
-  (`issues/libc-lacks-names-llvm-for-a-toyos-host-calls.md`), beside
-  those above. LLVM's shared libraries, `libLTO`, `libRemarks`, `libclang` and
+  (`issues/libc-lacks-names-llvm-for-a-toyos-host-calls.md`).
+- LLVM's shared libraries, `libLTO`, `libRemarks`, `libclang` and
   `libclang-cpp`, do not link against the C sysroot
   (`issues/a-shared-object-does-not-link-against-the-c-sysroot-with-z-defs.md`).
-  clang and lld use none of them, and ToyOS's build turns them off.
+- Bootstrap configures the build machine as LLVM's host
+  (`issues/a-toyos-hosted-llvm-is-configured-as-running-on-the-build-machine.md`).
+
+Owner: `issues/toyos-builds-itself.md`, M3.
 
 **Exit**: ToyOS's build, with nothing supplied by hand, has bootstrap install
-a clang and an `ld.lld` for `x86_64-unknown-toyos`.
+a clang and an `ld.lld` for `x86_64-unknown-toyos`, `cargo run --
+--hosted-clang` places those, and `src/hostedclang.rs`'s CMake configure and
+build are gone.

issues/libc-lacks-names-llvm-for-a-toyos-host-calls.md

@@ -6,18 +6,18 @@ opened: 2026-10-01
 
 # libc lacks names LLVM for a ToyOS host calls
 
-LLVM, clang and lld built for `x86_64-unknown-toyos`
-(`issues/bootstrap-cannot-build-llvm-clang-and-lld-for-a-toyos-host.md`)
-call five names libc neither declares nor defines:
+LLVM's tools built for `x86_64-unknown-toyos` call names libc neither
+declares nor defines. None is in the clang and `ld.lld` the build makes for
+ToyOS (`src/hostedclang.rs`), which compile and link without them; each
+stops a build of LLVM's other tools, bootstrap's among them
+(`issues/bootstrap-cannot-build-llvm-clang-and-lld-for-a-toyos-host.md`):
 
 - `shm_open` and `shm_unlink`, with which ORC maps memory on every Unix but
   Android (`llvm/lib/ExecutionEngine/Orc/MemoryMapper.cpp`,
   `TargetProcess/ExecutorSharedMemoryMapperService.cpp`).
 - `scanf`, which LLVM's interpreter hands an interpreted program
   (`llvm/lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp`).
 - `ctime`, with which `llvm-objdump` prints a file's time stamp.
-- `lround`, which libc++'s `std::lround` calls, from clang's `Basic` and its
-  static analyzer: clang does not link without it.
 
 **Exit**: libc declares and defines each, doing what POSIX says or refusing in
 POSIX's form, asserted by a guest C case that reads its effect back.

issues/libc-refuses-what-toyos-cannot-yet-answer.md

@@ -14,6 +14,7 @@ These answer failure in their POSIX form and do nothing
 - `symlink`, `ENOSYS`: `SYS_SYMLINK` displaces what its name held
   (`issues/a-symbolic-link-on-tmp-displaces-its-name-and-lists-nowhere.md`).
 - `chmod` and `fchmod`, `ENOSYS`: a file has no mode bits to set.
+- `utimes`, `ENOSYS`: no call sets a file's times.
 - `statvfs` and `fstatvfs`, `ENOSYS`: no call answers a filesystem's size or
   free space.
 - `getrlimit` and `setrlimit`, `ENOSYS`: no call answers a process's limits.

issues/no-guest-case-reads-std-filesystem.md

@@ -0,0 +1,20 @@
+---
+status: open
+kind: defect
+opened: 2026-09-30
+---
+
+# No guest case reads `std::filesystem`
+
+libc++ for ToyOS is built with `std::filesystem`, and `<fstream>` with it,
+over what libc gives `src/filesystem`: `setbuf`, `fseeko`, `ftello`,
+`truncate`, `pathconf`'s `_PC_PATH_MAX`, and `utimes`, which refuses
+`ENOSYS`, so `last_write_time` sets no time, and `remove_all` walks a
+directory by its path (`issues/remove-all-follows-a-link-swapped-in-mid-walk.md`).
+Each of libc's is read back by `tests/testcases/tinycc/207_libc_names.c`
+and `206_libc_refusals.c`; no C++ program in a guest uses any of it.
+
+Owner: `issues/toyos-builds-itself.md`, M2.
+
+**Exit**: a guest test lists a directory through `std::filesystem`, and reads
+a file back through `std::ifstream`.

issues/remove-all-follows-a-link-swapped-in-mid-walk.md

@@ -0,0 +1,26 @@
+---
+status: open
+kind: defect
+opened: 2026-10-09
+---
+
+# `remove_all` follows a link swapped in mid-walk
+
+Every C++ program on ToyOS gets libc++'s `std::filesystem::remove_all` built
+with `-DREMOVE_ALL_USE_DIRECTORY_ITERATOR` (`src/libcxx.rs`): it walks a
+directory by its path, and a directory swapped for a symbolic link between the
+walk's check and its descent sends the deletes wherever the link points,
+outside the tree it was asked to remove. libc++ says so of that walk
+(`libcxx/src/filesystem/operations.cpp`, "vulnerable to some race conditions",
+https://reviews.llvm.org/D118134), the class of CVE-2022-21658. Its other walk
+holds a descriptor for each directory and resolves every name against it
+(`openat`, `fdopendir`, `unlinkat`, `O_DIRECTORY`, `O_NOFOLLOW`,
+`AT_REMOVEDIR`), and ToyOS has no such descriptor: `open` refuses every
+directory, and the kernel resolves every path from the root.
+
+Owner: `issues/toyos-builds-itself.md`, M2, whose clang brought
+`std::filesystem` in.
+
+**Exit**: a directory opens as a handle that the kernel resolves names
+against, libc defines `openat`, `fdopendir` and `unlinkat` over it, and
+`src/libcxx.rs` passes no `REMOVE_ALL_USE_DIRECTORY_ITERATOR`.