-
Notifications
You must be signed in to change notification settings - Fork 41
PPC: Display data values on hover for pools as well #140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from 8 commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
135d21b
Fix missing dependency feature for objdiff-gui
LagoLunatic 774676e
Update .gitignore
LagoLunatic 70b4606
PPC: Display data values on hover for pools as well
LagoLunatic cdf3fd1
Tooltip data display: Format floats and doubles better
LagoLunatic 9051f48
Move big functions to bottom ppc.rs
LagoLunatic 507b988
Clear pool relocs in volatile registers on function call
LagoLunatic 9b1205d
Revert ObjArch API changes, add fake target symbol hack
LagoLunatic a51a5ac
Add hack to detect strings via the addi opcode
LagoLunatic 042fa9e
Move hack to resolve placeholder symbol into process_code_symbol
LagoLunatic dc46914
Merge reloc and fake_pool_reloc fields of ObjIns
LagoLunatic File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18,4 +18,4 @@ android.keystore | |
*.frag | ||
*.vert | ||
*.metal | ||
.vscode/launch.json | ||
.vscode/ |
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
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
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
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
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
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
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
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
Oops, something went wrong.
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason we can't store this in
reloc
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that, there's no scenario where
reloc
andfake_pool_reloc
need to both beSome
, so it might work. The reason I didn't do that initially is becausereloc
is accessed in many more places in the code than just the hover tooltip and I wasn't sure if I should be messing with all those without understanding them.I just checked all the references to
reloc
now:The JSON output of

objdiff-cli --output
(inInstruction::new
, might also be used by wasm?):The context menu when right-clicking on an instruction (in

ins_context_menu
):There are other places besides those 2 that reference the field, but I think they rely on the relocation's type being a supported one, not
R_PPC_NONE
, so they don't actually show up in a user-visible place in practice.Notice that if we go with this route there's no name, size, etc for the symbol being referenced here because of the hack where I replaced the target symbol with an empty placeholder.
Without the placeholder hack, the actual symbol is correctly displayed:

If you want I can merge the two fields and add checks to
Instruction::new
andins_context_menu
to skip showing the symbol if its name is empty. If this is done, any more references toObjIns.reloc
added in the future would also need similar checks to prevent the placeholder from being used.Alternative, maybe less hacky approach: instead of the hack where I resolve the placeholder to the real symbol in the GUI code for showing the tooltip every frame, I could do it just once diff/code.rs
process_code_symbol
and mutate the result before returning it.I didn't think of this before, but unlike
ObjArch::process_code
,process_code_symbol
already has access toobj.sections
without changing the function signature.This would allow the actual symbol name to be displayed everywhere more consistently. It would also avoid needing to add repetitive checks on
!target.name.is_empty()
every timeins.reloc
is used anywhere in the future to avoid bugs.Basically, anything that calls
process_code_symbol
would seereloc
as having the correct pooled reference target symbol. And it seems like objdiff only callsObjArch::process_code
viaprocess_code_symbol
.Do other projects that rely on objdiff like dtk use this
reloc
field for anything? Would it be bad for it to refer to an indirect pooled reference there?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed a couple commits with the changes I described above if you want to see for yourself if they're okay. From my testing it seems to work fine for both objdiff-gui and objdiff-cli and causes the fake relocation symbol to display everywhere the real one would:

I didn't test with other things like wasm/dtk.