The compiler adds some weak .bss variables not present in the original game, and because objdiff doesn't link the TU, it's expected that this would show <100% matching even though the TU actually does match.
The unexpected part is by just how much the matched data goes down. This .bss section is 0x1d1d8 bytes, and the unlinked one with extra weak symbols is 0x1D4E8 bytes, so I'd expect objdiff to show something like a 99% match. Instead it shows a 36% match.
When using objdiff-cli's report feature, this huge .bss section is counted as a significant percentage of the whole game's data. I would expect those extra 0x310 bytes to only decrease the matched data amount by a small bit, but instead it decreases it by over a hundred thousand bytes. The matched_data_percent field for the entire game decreased by more than 5% when these small weak symbols were added compared to the commit before that.
Version: v2.0.0-alpha.5
The compiler adds some weak .bss variables not present in the original game, and because objdiff doesn't link the TU, it's expected that this would show <100% matching even though the TU actually does match.
The unexpected part is by just how much the matched data goes down. This .bss section is 0x1d1d8 bytes, and the unlinked one with extra weak symbols is 0x1D4E8 bytes, so I'd expect objdiff to show something like a 99% match. Instead it shows a 36% match.
When using objdiff-cli's report feature, this huge .bss section is counted as a significant percentage of the whole game's data. I would expect those extra 0x310 bytes to only decrease the matched data amount by a small bit, but instead it decreases it by over a hundred thousand bytes. The
matched_data_percentfield for the entire game decreased by more than 5% when these small weak symbols were added compared to the commit before that.