Description
Version 2.0.0-beta.1 fixed #81 and now data symbols that get removed by the linked no longer drag the data match percentages down. It also seems to handle local static .bss variables (name$1234
) better than before.
However, it also introduced a new bug that causes the matched_data
field in reports to be either very low or zero in data sections that are completely matched or nearly completely matched.
Here is an objdiff-cli report generated with alpha.5:
report-alpha.json
And one generated with beta.1 (no changes to the code were made between these two reports):
report-beta.json
An example of a non-linked TU that is affected by this bug is framework/d/actor/d_a_player_main
.
alpha.5's report shows that 8956/21788 bytes of data match (this is an underestimate, it should be closer to 19000-20000/21788).
beta.1's report shows just 76/21788 bytes of data match.
But the bug also affects fully linked TUs where all the data is matching.
The beta.1 report's overall matched_data_percent
for the whole game is 22.42% (525719/2344668 bytes), which is actually lower than the percent that has been linked - 23.12% (541998/2344668 bytes).
alpha.5's report showed 28% data as matching, which should be closer to correct (but still probably a underestimate).
An example of a linked TU affected is d_a_am/d/actor/d_a_am
.
alpha.5 showed matched_data: 1404/1404 for the TU, and fuzzy_match_percent: 100% for each of the 3 sections.
beta.1 shows matched_data: 0/1404, and fuzzy_match_percent is only 100% for .text, but for .data it decreased to 96% and .rodata decreased to 98%.
Looking at the TU in objdiff GUI, it's not clear what data it considers nonmatching.
The percentage for the .data and .rodata sections did go down just like with objdiff-cli, the percentages for specific symbols did not go down, they're all still 100%.
The only specific symbols with a percentage lower than 100% are the ...data.0
and ...rodata.0
compiler-generated pools, which both show 0%, but that was already the case in alpha.5, so this isn't a new regression. They're also out of order, but again not new, so probably not related I assume.