fix: repair master — four merges landed code that does not compile

[srpatcha]

P0. master does not configure; once it does it does not build; once it builds one suite fails.

Every break has the same cause: a PR verified green on its own branch, squash-merged onto a base that had moved, and nothing re-verified the result. eBoot#58 diagnosed the identical pattern there.

1. CMake will not configure

CMake Error at tests/CMakeLists.txt:77 (add_executable):
  add_executable cannot create target "test_crypto_aes" because another target
  with the same name already exists.

#59 added registrations for test_crypto_aes and test_crypto_sha512 beside a block that already had them. Git merged it cleanly — this is not a textual conflict, which is why it was not caught. I flagged this exact hunk on #59 before it merged.

2. eos_task_set_current_internal defined twice

Two implementations with different behaviour — one clears g_current and marks the task RUNNING, the other silently returns. Kept the first: it is what the header documents ("Handles >= EOS_MAX_TASKS clear it") and what the mutex tests rely on. The second declaration's comment is folded into the survivor, since it records why the function exists at all.

3. sync.c does not compile — two PI designs spliced together

g_blocked_on, pi_propagate and task_valid are used and defined nowhere; original_prio is not a member of mtx_t.

#67 and #55 implement incompatible designs for the same feature. #67 recomputes effective priority from

effective = min(base_priority, priority of every waiter on every mutex held)

on every change; #55 saves and restores a value around each lock. Merging #55 after #67 deleted #67's implementation while leaving its call sites, so neither design survived intact.

Restored #67's. Save/restore is wrong when a task holds two mutexes and releases one, and wrong again when a task is boosted while already holding a mutex. It also subsumes #55: recomputing on timeout is one of the cases it recomputes on, and it already rejects a full waiter table rather than blocking a task that was never enqueued.

4. #74's tests merged without #74's parser change

Six assertions failed because a - name: item arriving while section == SEC_PKG_DEPS fell into the dependency branch, so the package after a deps: list was swallowed as a dependency of the previous one.

Verification

	before	after
cmake	configure fails	OK
build	—	0 errors
ctest	—	28/28

Also re-checked the package-overflow guard that arrived via #61/#65, since it landed in a different shape than #78 proposed: AddressSanitizer is clean on the 129-package config that previously overflowed, and the 129th entry is refused with a message rather than silently dropped.

🤖 Generated with Claude Code

---

Update — eos does not cross-compile for Cortex-M4

Pushed a second commit. With the ARM toolchain now available on my machine I built for the target this project exists to build for, and it fails:

$ cmake -B barm -DCMAKE_TOOLCHAIN_FILE=toolchains/arm-cortex-m4.cmake
$ cmake --build barm
core/src/log.c:113:9:  error: implicit declaration of function 'clock_gettime'
core/src/log.c:113:23: error: 'CLOCK_MONOTONIC' undeclared

get_timestamp_ms() had two branches — _WIN32, and "else, assume POSIX". Bare-metal newlib is neither. arm-none-eabi declares neither clock_gettime nor CLOCK_MONOTONIC, so the POSIX branch cannot compile for any Cortex-M target.

Also fixed one line down: uint32_t is unsigned int on x86-64 and unsigned long on 32-bit ARM, so the literal %u was wrong on exactly the target this build is for. PRIu32 is right on both.

Why CI did not catch it

The ARM job points CMAKE_TOOLCHAIN_FILE at cmake/arm-cortex-m4.cmake; the file is at toolchains/. That fails loudly — "Could not find toolchain file" — so the job has been red, not silently passing. But it dies at configure and never reaches the compile step where this bug lives.

The path is not new breakage: #75 fixed it, #79 and #51 carried the fix, and #59 reverted it — the same stale-base pattern as the other three repairs here.

Result

	before	after
ARM configure	missing toolchain file	OK
ARM build	2 errors in core/src/log.c	70/70 targets
artifact arch	—	armv7e-m
host ctest	28/28	28/28

Kernel and services together measure 15.8 KB flash, 26 KB RAM on Cortex-M4 — the first real footprint number this repo has produced.

[srpatcha]

Verified merge order for all nine open eos PRs

Nothing has merged and master is still red, so I applied every open PR in sequence onto origin/master locally and ran cmake && ctest after each step. This is the order that works.

#	PR	after merging	note
1	#82	28/28	must be first — master does not configure without it
2	#86	28/28	docs only
3	#85	28/28	clean
4	#87	28/28	clean
5	#88	28/28	clean
6	#89	28/28	clean
7	#90	28/28	clean
8	#83	29/29	one conflict — see below
9	#84	30/30	one conflict — see below

Final state of the full stack: 0 build errors, ctest 30/30, and the ARM cross-build produces 24 libraries reporting architecture: armv7e-m, footprint 15.8 KB flash / 26 KB RAM.

The two conflicts, and their resolutions

Both are in tests/CMakeLists.txt and neither is semantic.

#83 (GPS) — the branch predates test_devicetree and the fuzz subdirectory landing, so master's side is a strict superset. Keep master's block and add the test_gps registration to it.

#84 (stub-crypto signing) — its new test_crypto_failclosed registration sits inside the duplicated test_crypto_aes / test_crypto_sha512 block that #82 removes. That duplicate is the reason master currently fails to configure at all:

CMake Error at tests/CMakeLists.txt:83 (add_executable):
  add_executable cannot create target "test_crypto_aes" because another
  target with the same name already exists.

Keep the test_crypto_failclosed lines; drop the re-added aes/sha512 ones, which are already registered earlier in the file.

Why the order matters

#88, #89 and #90 were branched from a tree with #82 and #86 already applied, so they carry those changes. Merging them before #82 would work but makes the diffs harder to read. #83 and #84 go last only because putting the two conflicts at the end keeps the first seven merges mechanical.

Anything merged out of this order still lands — the sequence is what I verified, not the only one that exists.

[srpatcha]

Filed #92 to track the underlying defect. Re-verified the breakage today from a
fresh shallow clone of master, no local state:

kernel/src/sync.c:66:21:  error: 'mtx_t' has no member named 'original_prio'
kernel/src/sync.c:149:9:  error: implicit declaration of function 'task_valid'
kernel/src/sync.c:150:9:  error: 'g_blocked_on' undeclared
kernel/src/sync.c:206:5:  error: implicit declaration of function 'pi_propagate'
kernel/src/task.c:576:6:  error: redefinition of 'eos_task_set_current_internal'
build exit: 2

Still red, so this PR is still the gate. Every other open PR here is stacked
behind it: merging onto a base that does not compile reproduces the conditions
that caused this, and any CI result would again be describing a branch rather
than the result of merging it.

One thing #92 records that this PR deliberately does not fix, so it does not get
lost: the repository has no required status check.

$ gh api repos/embeddedos-org/eos/branches/master/protection
{"checks": null, "reviews": 1, "sigs": false}

required_status_checks is null. Nothing builds the merge result before it
becomes master, which is why four individually-green PRs combined into
something that had never been compiled in the form it landed in. sync.c is the
sharpest example — #55 and #67 implemented priority inheritance with
incompatible designs, one holding original_prio on the mutex and the other
g_blocked_on with pi_propagate(). Squashing both spliced half of each
together. Neither PR was wrong on its own.

Repairing the four breakages here does not stop the next overlapping pair from
doing the same thing. Marking the existing workflow required on master, once
this lands, is what closes it.

This is MERGEABLE and BLOCKED solely on wanting one approving review, which
I cannot supply as the author.