| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
something
Finishes the rebuild that was interrupted earlier and leaves the corpus on a single decoder version
for the first time since the SVC-opcode work started. All 16 modules rebuilt clean, 16/16 self-port
gates PASS, no duplicate names in any of the 99 builds, no address-derived names.
The naming fix from the previous commit is now actually in the artifacts: 1,038 SVC stubs use the
libdump's sysdrv_rpc_<N> convention instead of my own rpc_<N>. Six names persisted in fw/cgnames from
when I wrote them by hand are converted too, otherwise they would have quietly reintroduced the
inconsistency on the next rebuild. The 85 remaining bare rpc_ names are of the form gcp_asd_rpc_202 --
ASD's libdump names ported into other modules through shared code, so that is the libdump's own
convention and correct to leave.
Effect on diffs, which is why this mattered: the 22.0.4.49 -> 22.0.4.50 pair reported 8 functions
added and 8 removed with no firmware change behind it, and now reports 4. The remaining 4 are a
different and smaller problem, now documented in ta_diff.py: a function can carry a richer name in one
build than another, gcp_cmdFE0C against gcp_cmdFE0C_CreateCryptoSession, because the semantic half
comes from a pass that only reaches some builds.
Corpus-wide the diffs are now usable. Adjacent patch versions average 0.5 changed functions in ras,
2.5 in wspe, 3.3 in merit, 4.6 in opm, up to 26 in xgmi where the builds are genuinely far apart.
Added/removed should be read as "look at this" rather than ground truth; changed-function counts are
sound.
Metrics unchanged by the rebuild at 19,487 meaningful names (67.3%) and 75.8% field share, which is
the point -- it confirms the mixed-decoder tree was not inflating anything.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Earlier in this work I recorded that the SVC 0xF2 stubs "carry no semantic information whatsoever",
since the operation is chosen by caller-set registers. That holds for the shared thunks and I
over-generalised it: in the per-module stubs the opcode is loaded by the stub itself.
DTM's three unnamed functions all decompile to the same four lines, "SVC 0xF2; return 2". The bytes
say otherwise. MOV.W R0,#0x1C0, MOVW R0,#0x101 and MOV.W R0,#0x100, each stored as the first word of
the request frame before R0 is set to the selector and R1 pointed at the frame. So the first stored
word is the opcode, and 0x100 independently matches a comment already in this tree reading
"Opcode 0x100 - DTM TOPOLOGY_UPDATE", which is the corroboration that makes this more than a plausible
decode.
Named <ta>_rpc_<hex>, following the existing asd_rpc_NNN convention, and only where exactly one
in-range immediate survives -- otherwise the stub stays unnamed rather than guessed.
Also named by reading the bodies: oc_memcmp_ct, whose loop accumulates "v3 |= *a1++ ^ *a2++" over a
counted range with no early exit and is therefore a constant-time comparison worth labelling;
csu_rpc_309 and csu_rpc_305, the same stub shape with the opcode differing across builds; and
auc_sysdrv_rpc_101C_fwd, an 8-byte forwarder that adds a2+80 as a fourth argument.
csu, oc, tmz and dtm are now 100% named. Corpus 19,126 -> 19,134 meaningful names.
What remains in the small modules is an AUC body of several hundred lines, a RAP command handler and
five FP functions. That is per-function reverse engineering rather than pattern work, which is the
honest characterisation of the rest of the corpus too.
|
|
|
files
This pass fixes a fragility that was actively destroying work rather than adding coverage.
Four IDA databases have now come back corrupted with "worker exited with status 1", and the only
remedy is to delete and rebuild them. Every name derived by fw/ta_cgname.py lived solely in those
databases, so a rebuild discarded them -- GCP silently fell from 83% to 74% named when I wiped its
databases for the dispatcher fix, and I only noticed because I happened to re-measure per module.
Worse, those names cannot be re-derived: once a callee has a name it stops being a sub_* candidate,
so re-running the tool on an already-processed build reports nothing to do.
Three changes:
* fw/ta_cgname.py persists every name it applies to fw/cgnames/<ta>.json, keyed by build and
address.
* fw/ta_re.py re-applies that map at the start of each build, before anything reads names, so a
rebuilt database comes back with its derived names intact.
* fw/ta_snapshot_names.py recovers the names applied before the map existed. They are read out
of fw/decomp/*.index.json, which records name, address and tier per function, and only the
IDA tier is snapshotted. EXACT, MNEM, FUZZY and DISPATCH are deliberately excluded because
fw/ta_re.py re-derives them every run; persisting those would bake a derived result into the
repository and hide a future regression in the porting itself.
1476 names are now durable across 15 modules, including ASD's 847, which would otherwise have
needed a 40-minute wipe-and-rederive to recover.
Verified by doing the thing that caused the loss: XGMI's databases were deleted and rebuilt. It
came back at 238 of 334 named against 239 before, so a full database loss now costs one function
instead of nine percentage points. The single remaining loss is not chased down here, but it is
recorded rather than rounded away.
GCP is restored to 84% and HDCP re-derived cleanly to 86% with a complete map. Corpus naming
stands at 67.0%.
|
