Implement diffing relocations within data sections #154
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.
Because objdiff does not link the base object, and it only compares the raw bytes of data sections with each other, any differing relocations inside data will not show as a diff in the current version of objdiff. This can make them difficult to fix. And for objects that can't be linked and have their hash checked due to other reasons like regalloc or weak function ordering, it can be nearly impossible to even know when these issues exist in the first place, which can result in objects that appear equivalent but have nonequivalent relocations.
Some common cases where this can happen include*:
To help avoid this issue, this PR implements diffing for relocations in data.
In the data diff view, bytes that contain relocations that don't match will show highlighted as different, even though the bytes themselves (00) are the same:
Hovering over a row that contains at least one relocation will show all relocations in that row on that side (both matching and nonmatching relocations):
Which specific byte the user hovered over can't be detected, so multiple relocations in a single line will be shown together (hopefully this isn't too confusing).
You can also right click a reloc to copy its target symbol name:
In the symbol listing view, paired symbols that don't have matching relocations with their counterpart will show less than 100%:
Specifically, each byte containing a relocation will be counted twice for the percentage: once for if the value of the unlinked byte itself matches, and a second time for if the relocation matches.
The section's overall match percent will look at the entire section, not each individual symbol. This means that the section may show less than 100% even when each individual symbol's relocations match 100% when the symbols are out of order in the section, such as weak vtables:
When vtables are not out of order, but instead there are weak stripped vtables in the middle of the section, the diff looks a bit weird:
It shows a bunch of diffs here because the vtables are shifted, and so its diffing the stripped vtables with the unstripped vtables (this is a result of objdiff showing the entire section at once in the data diff view).
But I don't think this is a big deal as it doesn't show any diffs when you go back to the symbol list view, this is the same object:
I've only tested this for PPC architecture. In theory it should work on other architectures too, as I added arch-specific code to detect how many bytes each relocation takes up, but I'm not sure.
(*Specific examples of these issues that were found and fixed while testing this PR can be seen here zeldaret/tww@8e44641 and here zeldaret/tp@2189777)