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
Edit/Rename Variables Actions for function variables #2357
Edit/Rename Variables Actions for function variables #2357
Conversation
Is a popup saying |
The idea is to show this warning so that the user will know that it is the expected behavior. Otherwise, I think it might look like a broken feature. How often do people press N by mistake while the cursor is over a variable? Also, in order to close the warning dialog, you can press About the status bar, I think this is a bit too verbose to be shown in the status bar. As of now, you can see this dialog only if you press |
src/core/Cutter.cpp
Outdated
@@ -676,6 +676,11 @@ void CutterCore::renameFlag(QString old_name, QString new_name) | |||
emit flagsChanged(); | |||
} | |||
|
|||
void CutterCore::renameFunctionVariable(QString newName, QString oldName, RVA offset){ | |||
cmdRawAt(QString("afvn %1 %2").arg(newName).arg(oldName), offset); |
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.
There will be problems if variable name contains special symbols especially space.
Looks like the relevant part of afvn command is straight forward. Get function at offset, get function variable with old name, call rename on old variable. Don't forget about CORE_LOCK
.
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 have tried to use r2 API in the recently pushed changes. Please check.
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.
This is still incomplete and shows a slightly weird behavior where this stops working at times. Then I try to rename variable from disassembly, it works. And when I come back to the decompiler widget, that also starts to work. I get this message in the console.
WARNING: r_anal_function_get_var_byname: assertion 'fcn && name' failed (line 235)
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.
The assert is quite clear. The function expected that fcn and name are not null pointers but you passed a null pointer. You just need to follow the basic process of debugging - if something complains about bad value think did you expected to have a bad value there, if not where did the bad value came from, why did the code from which the bad value came returned a bad value, did you fulfill all the input requirements of function that returned you bad value, repeat the process until you locate the place where you made the mistake.
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 fixed this problem. I was using r2 API in the wrong manner. I thought r_anal_get_function_at()
would give us the function from any offset inside the function.
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.
R2 allows functions to overlap and the function range analysis isn't guaranteed to be identical between r2 and ghidra. I have seen both cases r2 splitting code into multiple smaller functions than ghidra and ghidra not being able to fully analyze a large switch statement when r2 could. To better handle such cases I strongly advice:
- pass the function addres to renameFunctionVariable thus allowing caller to decide if they have more precise information available than getFunctionStart/r_anal_get_functions_in. In the case of decompiler widget you already know the address of function which was decompiled.
- don't call
getFunctionStart
inrenameFunctionVariable
and update the documentation explaining that it expects the address of function instead of any address inside the function
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 will make this change.
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.
- In the case of decompiler widget you already know the address of function which was decompiled.
If you meant decompiledFunctionAddr
, is it also not fetched in the same manner?
decompiledFunctionAddr = Core()->getFunctionStart(addr);
dec->decompileAt(addr); ```
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.
That's not exactly the since after the function has been decompiled you can click on any address decompiler thought belongs to the function not only the ones that would be chosen when deciding which function to decompile.
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.
Changed as suggested.
src/menus/DecompilerContextMenu.cpp
Outdated
actionEditFunctionVariables.setToolTip(tr("Can't edit this variable." | ||
"<br>Only local variables defined in disassembly can be edited.")); |
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.
actionEditFunctionVariables.setToolTip(tr("Can't edit this variable." | |
"<br>Only local variables defined in disassembly can be edited.")); | |
actionEditFunctionVariables.setToolTip(tr("Can't edit this variable.<br>" | |
"Only local variables defined in the disassembly can be edited.")); |
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.
Done.
tooltip for disabled action left
changes to editvariabledialog's title
and update submodule
5b67dc8
to
699b26a
Compare
* Edit Function Variables Action * Rename Function Variables Action * CutterCore::renameFunctionVariable
* Edit Function Variables Action * Rename Function Variables Action * CutterCore::renameFunctionVariable
* Edit Function Variables Action * Rename Function Variables Action * CutterCore::renameFunctionVariable
* Edit Function Variables Action * Rename Function Variables Action * CutterCore::renameFunctionVariable
* Edit Function Variables Action * Rename Function Variables Action * CutterCore::renameFunctionVariable
* Edit Function Variables Action * Rename Function Variables Action * CutterCore::renameFunctionVariable
* Edit Function Variables Action * Rename Function Variables Action * CutterCore::renameFunctionVariable
* Edit Function Variables Action * Rename Function Variables Action * CutterCore::renameFunctionVariable
* Edit Function Variables Action * Rename Function Variables Action * CutterCore::renameFunctionVariable
* Edit Function Variables Action * Rename Function Variables Action * CutterCore::renameFunctionVariable
Your checklist for this pull request
Detailed description
This PR implements edit variable action and rename variable action for function variables(function parameters and local variables).
See GIFs below.
1. Both actions working for variables that are defined in radare2.
2. Disabled actions and tooltips for them. Actions are disabled when the variable represented by the annotation is not present in radare2.
3. When the rename variable action is triggered by shortcut for a variable that doesn't exist in radare2.
4. When the edit variable action is triggered by shortcut for a variable that doesn't exist in radare2.
Test plan (required)
and checkout commit rizinorg/rz-ghidra@ac829cb. Compile it.Closing issues