fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the unreached code -- five mechanisms eliminated, nothing in the file names it

Browse Source 
Inverting the question -- read what an unreached routine DOES, rather than testing
another candidate mechanism -- sharpened this a lot without solving it.

The metric was partly inflated.  Of 24901 unreached instructions in 564 runs, 458 runs
are length 1, and 111 of those are a lone `ret` stranded after an end_coroutine, with
the next routine being a properly seeded entry.  Stage 02's first two "unreached
routines" are exactly that.  But those are only 458 instructions: the real gap is
24443 in 106 runs, the largest 1526 (Stage 26), 1496 and 1481 (Stage 29), 1069, 904.

And it is live mission logic.  Stage 26's 1526-instruction run stages arguments and
calls builtin57(ADN110, 1) and set_group_speed(ADN110, 2, 0) -- named units, named
built-ins.

New this iteration: kill_coroutine (built-in 5) is confirmed as a code-offset carrier,
which is what the corpus said -- its local[0] resolves 150/150 onto the instruction
stream against a 34.0% control, values 13740..221048.  And, like the others, it points
at zero unreached run-starts.

That is now five mechanisms.  Across 2757 code references -- start_coroutine 1765, the
phase timeline 675, built-in 19's trigger handlers 79, kill_coroutine 150, and the
0x1883 records 88 -- not ONE lands on an unreached run-start.  A categorical absence,
not a near miss.

Not a tool artefact: 1765 of 1765 start_coroutine sites resolve with 0 missed, 0
entries land outside their phase region, and 0 are discarded by the on-stream filter.

Combined with the earlier result that an unreached routine's offset appears nowhere in
the file as a word in any encoding, these routines are referenced by nothing inside the
.ssb.  Either they are unused in this build, or they are entered from outside it.  A
1526-instruction routine driving a named squadron sits badly with "unused", but that
discomfort is not evidence and the two readings are recorded without choosing.

No static test I have devised can decide it; a runtime probe logging sub_822737C8's
third argument through a mission would.

All artefacts regenerate byte-identical; documentation only.
This commit is contained in:
Sylpheed RE agent
2026-08-27 07:46:56 +00:00
parent 1c21a00f7c
commit 42544b4969
2 changed files with 104 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/re/BACKLOG.md
View File

@@ -135,6 +135,24 @@ unknown, what evidence exists, and what the first step would be. Move an item in
🟡 **Still does not explain the unreached code** — 0 of the 79 handler offsets are
unreached run-starts.
* 🟡 **(2026-08-27) THE UNREACHED CODE — five mechanisms eliminated, nothing in the
file names it. [isl-unreached-code](isl-unreached-code.md).** Inverting the question
(read what an unreached routine DOES) sharpened it. **Metric partly inflated:** of
24901 unreached instructions in 564 runs, **458 are length-1** (111 a lone `ret`
stranded after `end_coroutine`) — but the gap is real: **24443 instructions in 106
runs**, up to **1526** long. It is live logic: Stage 26's biggest run calls
`builtin57(ADN110,1)` and `set_group_speed(ADN110,2,0)`. 🔑 **NEW: `kill_coroutine`
(built-in 5) confirmed as a code-offset carrier — 150/150 on-stream vs a 34.0 %
control** — yet **0 unreached run-starts**, the fifth such result. Across **2757
code references** from five mechanisms (`start_coroutine` 1765, timeline 675,
built-in 19 triggers 79, `kill_coroutine` 150, `0x1883` 88), **not ONE lands on an
unreached run-start.** ✅ Not a tool artefact: 1765/1765 `start_coroutine` entries
resolve, 0 outside a phase region, 0 dropped by the on-stream filter. 🟡 With the
earlier "the offset appears nowhere as a word in any encoding", these routines are
referenced by **nothing inside the `.ssb`** — either unused in this build, or
entered from outside it. ▶️ **No static test I have devised can choose**; a runtime
probe on `sub_822737C8`'s third argument would.
## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
`XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the

86
docs/re/isl-unreached-code.md Normal file
View File

@@ -0,0 +1,86 @@
# 🟡 The unreached code — five mechanisms eliminated, and nothing in the file names it
Inverting the question (read what an unreached routine *does*, instead of testing
another candidate mechanism) sharpened this considerably without solving it.
## ✅ The metric was partly inflated — but only partly
Over all 28 stages: **24 901 unreached instructions (15.0 %) in 564 runs.**
| | |
|---|---|
| runs of length 1 | **458** |
| …of those, a lone `ret` (op 20) | 111 |
| **instructions in runs longer than 1** | **24 443 — 14.7 %** |
The length-1 runs are dead terminators: a `ret` stranded after an
`end_coroutine`, with the *next* routine being a properly seeded entry. Stage 02's
first two "unreached routines", `0x000D8C` and `0x002C00`, are exactly this — the
code immediately after each is the phase main entry and a timeline target.
But they are only 458 instructions. **The gap is real: 106 runs, several of them
huge** — 1526 (Stage 26), 1496 and 1481 (Stage 29), 1069, 904, 860.
## ✅ And it is live mission logic
Stage 26's 1526-instruction run:
```
004BD8: local[0] = 1 ; local[4] = 1 ; local[8] = 1
004C08: call builtin57(ADN110, 0x1)
004C44: local[16] = 0.0
004C60: call set_group_speed(ADN110, 0x2, 0)
```
Named units, named built-ins, staged arguments. Not padding, not scratch.
## 🔴 FIVE mechanisms carry code offsets — and none points at it
Every construct in the file that names a routine has now been enumerated and
tested against the unreached run-starts:
| mechanism | references | on the instruction stream | control | **unreached run-starts** |
|---|---|---|---|---|
| `start_coroutine` (built-in 1) | 1765 | 1765 (100 %) | — | **0** |
| the phase TIMELINE | 675 | 675 (100 %) | 33.3 % | **0** |
| built-in 19's trigger handler | 79 | 79 (100 %) | 27.8 % | **0** |
| **`kill_coroutine` (built-in 5)** | **150** | **150 (100 %)** | **34.0 %** | **0** |
| the `0x1883` records | 88 | 82 (93 %) | — | (they *were* the 5 exits) |
`kill_coroutine` is new this iteration and confirms the corpus's reading — its
`local[0]` is a phase-relative code offset, 150/150, values 13 740…221 048.
**Across 2 757 code references, not one lands on an unreached run-start.** That
is not a near miss; it is a categorical absence.
## ✅ Not a tool artefact
The obvious suspicion is that my entry extractor drops targets. It does not:
* **1765 of 1765** `start_coroutine` sites resolve — **0 missed**.
* **0** entries land outside their phase's region.
* **0** entries are discarded by the "must be on the instruction stream" filter.
## 🟡 Where that leaves it
Combined with the earlier result that an unreached routine's offset appears
**nowhere in the file as a word**, in any encoding (phase-relative, absolute, and
both /4 forms, all at or below their controls), the conclusion is that these
routines are **referenced by nothing inside the `.ssb`**.
Two readings remain, and this work does not choose between them:
1. they are **unused in this build** — compiled from source that the shipped
mission never enters; or
2. they are entered from **outside the file** — a table in another pak, or engine
code holding an offset.
⚠️ Reading (1) is not comfortable with a 1526-instruction routine that
manipulates a named squadron, but "uncomfortable" is not evidence.
## 🟡 Not settled
* Which of the two readings is right. A runtime probe — breaking on
`sub_822737C8` and logging its third argument through a mission — would decide
it, and no static test I have devised can.
* Whether the 106 runs are one phenomenon or several.