From 6a8c366a11837b05b2a804be6a31117b28890db0 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Mon, 24 Aug 2026 10:16:12 +0000 Subject: [PATCH] formats: correct the glyph class - a SECONDARY vtable of adjustor thunks The first write-up called 0x820B2A64's 32 entries "methods" and the three xrefs to it "construction sites". The DB's disassembly refutes both: every slot points at a 16-byte adjustor thunk - lwz r11,-4(r3); subf r3,r11,r3; b - which is the PPC/MSVC thunk for a SECONDARY base subobject. So this is a secondary vtable and the class uses multiple inheritance, and sub_823C3148, listed as a constructor because it references the table, is actually the branch target of one of the table's own thunks. Following the 32 branch targets instead: 32 distinct addresses, 18 of them known function starts, in two clusters (0x823c3xxx beside the thunks and 0x823e3xxx), and NONE of them appears in any of the 1150 vtables the DB classified - so nothing places this class in a named hierarchy, the disc's RTTI having no class names. The two-cluster split is noted as a reading rather than a measurement. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE --- docs/re/structures/hud-glyph-quad.md | 39 +++++++++++++++++++++++----- 1 file changed, 32 insertions(+), 7 deletions(-) diff --git a/docs/re/structures/hud-glyph-quad.md b/docs/re/structures/hud-glyph-quad.md index a15ab0f4..020c6385 100644 --- a/docs/re/structures/hud-glyph-quad.md +++ b/docs/re/structures/hud-glyph-quad.md @@ -11,14 +11,39 @@ words moving with `REMAINING OB` are four ASCII digits and four guest pointers. Following the pointers lands on four objects with an identical shape, whose first word is `0x820B2A64`. -## It is a vtable, with three constructors +## It is a SECONDARY vtable — 32 adjustor thunks -Read out of guest memory: **32 consecutive code pointers**, all inside -`0x823c43b0 … 0x823c45a0`, terminated by `0xfffffffc`. `sylpheed.db` has three -`ref` xrefs to it, from `sub_823C3060`, `sub_823C3148` and `sub_823C31E0` — three -construction sites, the same pattern the splash item vtable `0x820b30b4` shows. -The DB does not classify `0x820B2A64` itself as a vtable and knows no name for -it, which is expected: the disc's RTTI carries no class names. +Read out of guest memory: 32 consecutive code pointers in `0x823c43b0 … +0x823c45a0`, terminated by `0xfffffffc`. + +🔴 **Corrected 2026-08-24, same session.** The first write-up called these "32 +methods" and the three xrefs to the table "three construction sites". Both were +wrong, and `sylpheed.db`'s disassembly says why — every slot points at a +**16-byte adjustor thunk**: + +``` +lwz r11, -4(r3) ; the this-adjustment stored just before the object +subf r3, r11, r3 ; fix up `this` +b +.long 0 +``` + +That is the classic PPC/MSVC thunk for a **secondary base subobject**, so +`0x820B2A64` is a *secondary* vtable and the class uses multiple inheritance. +`sub_823C3148`, which the first write-up listed as a constructor because it +*references* the table, is in fact the branch target of one of the table's own +thunks. + +**Where the real methods live.** Taking the 32 branch targets: 32 distinct +addresses, **18** of them known function starts in `sylpheed.db`, in two clusters +— `0x823c3xxx` (beside the thunk block itself) and `0x823e3xxx`. The rest land on +further stubs immediately after the block. **None** of the 32 appears in any of +the 1 150 vtables the DB classified, so nothing places this class in a named +hierarchy; the disc's RTTI carries no class names. + +The two clusters are what a derived class looks like — its own overrides next to +its own thunks, and inherited implementations elsewhere — but that is a reading, +not a measurement. ## The instance