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

formats: correct the glyph class - a SECONDARY vtable of adjustor thunks

Browse Source 
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 <method> - 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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-24 10:16:12 +00:00
parent 80331f66b4
commit c77d51afc0
1 changed files with 32 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
docs/re/structures/hud-glyph-quad.md
View File

@@ -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 <the real method>
.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