Restore card globals to extern in hsd_3A94, rematching 4 functions - #3031
Open
Danny-Dasilva wants to merge 3 commits into
Open
Restore card globals to extern in hsd_3A94, rematching 4 functions#3031Danny-Dasilva wants to merge 3 commits into
Danny-Dasilva wants to merge 3 commits into
Conversation
The hsd_3AA7 merge (doldecomp#3029 upstream) turned the shared card work-area globals into in-TU definitions (several static). MWCC then addresses the static arrays through anonymous section anchors instead of named symbol relocations, which regressed previously-matched functions. Declaring them extern (as the pre-merge TU did) restores: hsd_803AAA48 99.13 -> 100.00 fn_803ADE4C 95.44 -> 100.00 fn_803B1F78 98.36 -> 100.00 fn_803B21E8 95.86 -> 100.00 No other function changes (verified with objdiff report changes against the merge-base build).
Report for GALE01 (013091a - 9425610)📈 Matched code: 85.51% (+0.19%, +7264 bytes) ✅ 7 new matches
📉 1 regression in an unmatched item
|
Defining this data inside hsd_3A94.c makes mwcc use anchor-form addressing there, which is what regressed the card functions in the first place — so it gets its own data-only TU instead, following the efdata.c/gmvsdata.c pattern. Sizing hsd_804D2648 at its real 0x828 bytes (a JpegWork, not just the __jmp_buf it is declared as by users) brings the unit's data to 9596/9596 matched, above the 89% the in-TU definitions achieved.
hsd_804D79AC..hsd_804D79C8 were declared in hsd_3A94.h but never defined anywhere. hsd_804D79B0 is a byte scalar (see its uses in hsd_3B34.c); its symbols.txt size covered the 7-byte alignment gap to hsd_804D79B8, which no source definition can reproduce. Both unit data sections now report 100%.
Danny-Dasilva
marked this pull request as ready for review
August 9, 2026 06:05
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#3029 turned the shared card work-area globals into in-TU definitions, several of them
static. MWCC addresses static arrays through anonymous section anchors instead of named symbol relocations, which regressed four functions that were fully matched before the merge. Restoring the declarations toextern(as the pre-merge TU had them) brings them back:hsd_803AAA48fn_803ADE4Cfn_803B1F78fn_803B21E8Since defining this data anywhere in hsd_3A94.c re-triggers the anchor addressing, the definitions live in a new data-only TU
hsd_4D11.c(same pattern asefdata.c/gmvsdata.c), which links and keeps the DOL verifying. Two data fixes fall out of sizing it correctly:hsd_804D2648is really 0x828 bytes (a JpegWork per hsd_3B34.c, not just the__jmp_bufit's declared as).hsd_804D79AC..hsd_804D79C8were declared but never defined;hsd_804D79B0is a byte scalar whose symbols.txt size was covering an alignment gap.Both units' data sections now report 100% matched (
.bsswas 89.08% before this PR):hsd_4D11.bsshsd_4D11.sbsshsd_3A94.sbssVerified with
objdiff-cli report changesagainst the base build: the four functions above and the data split are the only changes.Reading the report: the diff will show
hsd_3A94 .bss 89.08% → 0%. No data was lost — the.bssrange moved tohsd_4D11, where it now matches 100% (it never fully matched before). The report just renders "this unit no longer has a.bsssection" as 0%. Net effect across both units is about +1 KiB of newly matched data.