fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: the +184 writer is blocked - and xrefs.ind_call is a CROSS PRODUCT, not a call graph

Browse Source 
Chasing what supplies the EX_ mode word. Two routes, both measured to have no
power, plus one structural fact that did come out.

The offset route is dead. stw ..., 184(rN) occurs 301 times in the image, lwz
from +184 occurs 351 times, and 115 functions touch both +144 and +184. +184 is
an ordinary small offset shared by many unrelated classes - the same shape the
corpus already recorded as failing three times. Nothing narrows to a writer.

The bigger result is an instrument refutation with corpus-wide reach. Asking
xrefs for the callers of the two screens returns 633 sources for EACH, and the
two lists are IDENTICAL, which cannot be right. Measuring the relation itself:

  ind_call rows                       1827297
  distinct targets                       1710
  distinct sources                       6992
  targets with EXACTLY 633 sources        236

236 different functions sharing an identical source count is the signature of an
unresolved-indirect-call cross product, not of a call graph. Any reading that
treats an ind_call edge as "X calls Y" is void, here and anywhere else in the
corpus it may have been used.

The control shows the other kinds are sound: sub_82286BC8 has exactly one
caller, kind call. And both EX_ screens have ZERO non-ind_call edges - they are
reached only through function pointers, which is why the direct graph is empty
for them.

What did come out: scanning the entries of all 1150 catalogued vtables in the
flat .pe, both EX_ screens are slot 1 of their own class - sub_822814D8 in
ANON_Class_271D5F25 and sub_8227A3A0 in ANON_Class_CAA8AD62 - while sub_82286BC8
is in no catalogued vtable at all. So the 2/0/0/1 partition from the previous
commit reflects a structural difference rather than a coincidence: the two
screens that select on the mode word are vtable methods of their own classes and
the one that does not select is not a vtable method.

Still not settled: what writes +184. Both the offset sweep and the call graph are
exhausted for it. A route with actual power would be the RTTI behind those two
anonymous classes, or a runtime watch on the field - not another static offset
search.

All seventeen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 11:08:18 +00:00
parent 35a35f753f
commit 749567e835
2 changed files with 82 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
docs/re/structures/result-screens.md
View File

@@ -131,3 +131,56 @@ at **`+144`** of the stage-loader class, while the word tested here is at
**`+184`** of `[object + 4]`. Same constant, same `EX`/`EXTRA` naming, two
different offsets in what may be two different objects — **that the two fields
are the same field is not shown**, only that both compare a mode word against 3.
## 🔴 Who writes `+184` — blocked, by two independent instrument failures
The next question after the selector is what *supplies* the mode. Two routes
were tried and both are measured to have no power here.
**The offset route has no power.** `stw …, 184(rN)` occurs **301 times** in the
image, `lwz` from `+184` **351 times**, and **115 functions touch both `+144`
and `+184`**. `+184` is an ordinary small offset shared by many unrelated
classes — the same shape that the corpus already recorded as failing three
times. Nothing here narrows to a writer.
**❌ The `xrefs` `ind_call` edges are a cross product — do not use them as
callers.** Asking for the callers of the two screens returns **633 sources for
each, and the two lists are identical**, which cannot be right. Measuring the
relation itself:
| | |
|---|---|
| `ind_call` rows | **1 827 297** |
| distinct targets | 1 710 |
| distinct sources | 6 992 |
| **targets with *exactly* 633 sources** | **236** |
236 different functions sharing the identical source count is the signature of
an unresolved-indirect-call cross product, not of a call graph. ⚠️ **Any reading
that treats an `ind_call` edge as "X calls Y" is void**, here and elsewhere in
the corpus.
⚠️ The control shows the *other* kinds are fine: `sub_82286BC8` has exactly
**one** caller, kind `call`. And both `EX_` screens have **zero** non-`ind_call`
edges — they are reached only through function pointers, which is why the direct
graph is empty for them.
### ✅ What did come out: both `EX_` screens are slot 1 of their own class
Scanning the 1 150 catalogued vtables' entries in the flat `.pe`:
| function | vtable | slot |
|---|---|---|
| `sub_822814D8` (debriefing) | `ANON_Class_271D5F25` | **1** |
| `sub_8227A3A0` (career) | `ANON_Class_CAA8AD62` | **1** |
| `sub_82286BC8` (save) | *in no catalogued vtable* | — |
So each `EX_`-selecting screen is a class whose **slot-1 virtual** is its
key-list builder, and the third — which selects nothing — is not a vtable method
at all. That is consistent with the 2 / 0 / 0 / 1 partition above arriving from a
structural difference rather than a coincidence.
🔴 **Still not settled: what writes `+184`.** Both the offset sweep and the call
graph are exhausted for it. A route with actual power would be the RTTI class
behind `ANON_Class_271D5F25` / `_CAA8AD62`, or a runtime watch on the field —
not another static offset search.