Skip to content

objdiff-cli beta.1 data match percentage regression #84

Closed
@LagoLunatic

Description

@LagoLunatic

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.
image

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions