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

re: the trigger-queue appender is built-in 25 -- the script appends, not the engine

Browse Source 
isl-builtins.md carried the trigger queue at phase+272 a long way -- layout, live
count at +272+20, the generic appender sub_8226EAB8 -- and stopped at "what actually
appends a node is still unidentified", proposing a gdb watchpoint on a running
emulator.  It is a static question after all.

sub_8226EAB8 is a shared helper with 16 callers, so it cannot be identified by name.
But the corpus records that the trigger container EMBEDS its inner list at +12, so the
appender must hand it container+12.  Only two of the sixteen callers do, and one sets
its base 34 instructions earlier:

  8226A22C  addi r29, r24, 272     ; r24 = the ScriptPhase
  8226A2B4  addi r3,  r29, 12      ; -> phase + 272 + 12
            bl   0x8226EAB8

phase+272+12 is exactly the inner list whose count the corpus watched at +272+20.

sub_8226A0D8 is ScriptPhase vtable SLOT 28, which is what BUILT-IN 25's stub
tail-calls, and there are ZERO real `bl 0x8226A0D8` instructions in the image -- it is
reached only through the vtable.  So the queue is populated by the SCRIPT, retiring
the residual "the engine moves records into the phase's queue each frame" reading that
isl-builtins.md had already flagged as unsupported by its own call site.  Built-in 25's
arguments agree with two independently measured tables: UNIT_ARG (a unit at local[4])
and SYM1_SLOTS[12] (a symtab-1 name at local[12]).

REFUTED in the same pass, with a control: built-in 25 does NOT carry the coroutine
entry that a trigger fires, which would have seeded the 389 routines reachable from no
static entry.  Taking each staged operand as a code offset from the phase base, 0 of 8
land on an instruction boundary, against 38.7% for an arbitrary 4-aligned offset --
below chance, not above it.  And the scale is wrong regardless: built-in 25 has only
2 call sites in Stage 02.

So what starts the unreachable routines is still open, and it is not this.  A trigger
node's own layout and its consumer are unread, and built-in 25 stays unnamed.
This commit is contained in:
Sylpheed RE agent
2026-08-27 06:42:47 +00:00
parent 6cbfe0524f
commit 6c9e2ca44d
3 changed files with 99 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/re/BACKLOG.md
View File

@@ -6,6 +6,20 @@ unknown, what evidence exists, and what the first step would be. Move an item in
---
* ✅ **(2026-08-27) The trigger-queue appender is IDENTIFIED — [isl-trigger-queue](isl-trigger-queue.md).**
`isl-builtins.md` left "what actually appends a node is still unidentified" and
proposed a gdb watchpoint; it is static after all. The container embeds its inner
list at `+12`, so the appender must pass `container+12` to the generic helper
`sub_8226EAB8` — only 2 of its 16 callers do, and one of them sets
`addi r29, r24, 272` first. That is **`sub_8226A0D8` = ScriptPhase vtable slot 28
= BUILT-IN 25**, with **ZERO real `bl`s** in the image, so it is reached only as a
built-in: **the SCRIPT appends triggers, not the engine.** 🔴 **REFUTED in the same
pass:** built-in 25 does NOT carry the coroutine entry a trigger fires — 0 % of its
staged operands land on an instruction boundary against a **38.7 %** chance control,
and it has only **2 call sites in Stage 02**, far too few for ~15 % of the code. So
what starts the 389 unreachable routines is **still open**. 🟡 A trigger node's
layout and its consumer are unread; built-in 25 stays unnamed.
## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
`XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the