| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
exposed
Asked whether the artifacts can produce meaningful version diffs yet. They could not, and measuring
why gave a tool and a bug.
A raw diff of two adjacent GCP builds changes 6-17% of lines, almost none of it firmware. The noise
has four sources, measured: tier annotations like [tier=MNEM size=22] against [tier=EXACT size=22],
which record how a name was derived rather than what the code does (42 of 302 changed lines on one
pair); address-derived tokens such as off_40480C -> off_40481C and loc_4057E8 -> loc_4057F8, which
shift wholesale when code is inserted upstream and whose normalisation alone takes one pair from 405
changed lines to 175; raw hex in JUMPOUT(0x4055E4); and IDA resolving a call site to a name in one
build and loc_* in another, plus local renumbering.
ta_diff.py normalises all four and reports per function rather than per line. On 22.0.0.73 ->
22.0.0.77 that turns 405 changed lines into 3 changed functions out of 111, and what survives is
worth reading: two new switch arms, case 0x26 and case 0x27, in
gcp_cmdFE08_KeyExchangeAuthenticatedSession -- new command IDs, which is the kind of finding this
corpus exists to surface. Across the module, adjacent patch versions now show 2-7 changed functions
and version-family jumps show 30-odd added and removed, which is the expected shape.
The tool immediately caught a naming bug of mine. It reported 8 functions added and 8 removed between
22.0.4.49 and 22.0.4.50 with no firmware change behind it: the SVC-opcode pass emits <ta>_rpc_<HEX>
while the libdump calls the same functions <ta>_sysdrv_rpc_<N>, and the decoded digits already agree
exactly, so only the prefix differed. The pass now uses the libdump's convention. 1,188 names are
affected and will align on the next regeneration.
Not yet regenerated, so the corpus still carries the old convention; that is deliberate rather than
forgotten, since a 10-module rebuild was interrupted earlier and the tree already mixes two decoder
versions in gcp, opm and hdcp.
|
