r2ghidra doesn't work with radare 5.0.0
Closed this issue · 26 comments
sudo dpkg -i radare2*5.0.0*.deb
r2pm -i r2ghidra
r2 -A baby_reverse
[0x00001200]> s main
[0x000012e9]> pdg
Ghidra Decompiler Error: No print languages registered
i can reproduce this issue. it's not a bug in r2. thanks for reporting, i'm taking care of it
I did a workaround in the r2pm package. Ill do the proper fix when i find some spare time
Is that related to the next error message I'm receiving?
error: pathspec 'r2-5.0.0' did not match any file(s) known to git
Nope, that means there’s no such tag for this version, so it may use HEAD. I’ll hide this message to not confuse users. Thanks!
I also have some problem building the plugin from the sources along with radare2 5.0!
Here is the first build error I get:
In file included from /home/fleury/.local/share/radare2/r2pm/git/r2ghidra/src/core_ghidra.cpp:3:
r2ghidra/src/R2Architecture.h:46:10: error: ‘Scope* R2Architecture::buildGlobalScope()’ marked ‘override’, but does not override
46 | Scope *buildGlobalScope() override;
| ^~~~~~~~~~~~~~~~
r2ghidra/src/core_ghidra.cpp:635:18: warning: ‘radare_plugin’ initialized and declared ‘extern’
635 | R_API RLibStruct radare_plugin = {
| ^~~~~~~~~~~~~
make[2]: *** [CMakeFiles/core_ghidra.dir/build.make:82: CMakeFiles/core_ghidra.dir/src/core_ghidra.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:213: CMakeFiles/core_ghidra.dir/all] Error 2
make: *** [Makefile:149: all] Error 2
This error seems linked to the fact that the database.hh
in the code of the Ghidra decompiler source code does not define anymore buildGlobalScope()
function. It has been wiped out recently (last September in fact).
I have been investigating this problem a bit... In fact, this is due to a change in the Ghidra API in managing the Scopes. I managed to fix it, but I run into other problems which are (again) caused by Ghidra API changes. What are the plans to fix these?
For the others, a simple workaround would be to drop the very last commit.
Probably the easiest way to solve that ist just ripping the last commits from rz-ghidra. Anyone in the mood to make a PR with this?
Also, recently, ghidra decided to commit the autogenerated C files from the Bison/Flex output, because some stuff they are using is not portable and was causing some builds to fail (in macOS at least). so we can probably just get rid of bison/flex dependencies too.
Im not a big fan of ripping the whole ghidra repo just to build few files from a directory, so we could also keep a copy of the decompiler separately and ship it inside the r2ghidra source tarball, otherwise i dont see how distros would package this thing.
We in Arch Linux are currently simple building from a git tag like this: https://github.com/archlinux/svntogit-community/blob/packages/r2ghidra-dec/trunk/PKGBUILD
I think mostly all distros support similar build input, at least Debian even actively mirrors the whole git repo (plus a debian dir)
Same Issue! with 5.0.1 too....
I am not sure that a PR would be the best way to get out of this problem. What you should do (in my humble opinion) is the following:
#> git reset --hard HEAD~
#> git push --force
That would help everybody to get a fully functional code.
It will remove the last commit which is messing up everything.
@perror the last commit is using an existing reference in the correct ghidra submodule. Without that commit I couldn't even do anything, that is referencing an orphan commit object not contained in any branch or tag. The appropriate fix would be to backport rz-ghidra to the radareorg repo whatever is required to make r2ghidra work.
@anthraxx Reverting the last commit will just revert the reference of the submodule to the previous refered Ghidra version which was working fine. I suspect that you tried my command after having updated the submodule. You should execute the commands I advised on a freshly cloned (with "empty" submodules) repository. But, it works. I can ensure it.
@perror dude are you recurringly thinking im stupid and you need to explain what a reset and force push is (btw force push is the wrong thing to do here anyway and if ever you should use --force-with-lease anyway)?
The commit is referencing an orphan object. if that is an appropriate commit then the orphan commit should be anchored to a branch and the submodule updated again. the r2ghidra branch of the radareorg/ghidra repo is what the submould should point to.
Well, the fact that the submodule is refering to an orphaned node is indeed a problem... But, the commit that you pushed is not solving any problem at all, on the contrary it just ruin the build of the whole software. In fact, you may have noticed it if you had a look at the result of the output of the automated tests.
So, reverting the last commit is probably the best move to take right now. IMHO
It solved that the commit is invalid and can't be referenced in a sane environment that doesn't just blindly pull in all objects from github, github namespaces any fork, PRs and other objects into the same git namespace for performance and functionality.
While its orphan you can even see the warning on GH: https://github.com/radareorg/ghidra/commit/7bde3b54b43230601363f89b0214ab4bdba8bf6f
You are repeatably ignoring what I'm saying just so you dont need to accept you are wrong.
I repeat myself yet again in hope that you read it this time:
"if that is an appropriate commit then the orphan commit should be anchored to a branch and the submodule updated again.
Then, I should as well repeat myself again and say that your last PR is just preventing r2ghidra to build properly...
dude you are a waste of time, I'm ignoring any input of yours now. in confident @radare is sane to do the right thing
Well, what can I say more then... Reality is not something that you can ignore for a long time. You will have to face it one day or another... with me or without me. And, believe me, I did not meant to be mean at all. Sorry if you understood it like that.
Ok lets face reality:
- You are proposing a "fix" to force push a live published master branch that is such a anti pattern I can't even believe you consider that a sane approach
- You are repeatably ignoring what would be an appropriate fix for both, using the old commit and not referencing an orphan object outside of the repository just to push your agenda and not face reality that you "solution" still breaks stuff on other ends
- The only thing you do is blame I have been submitting that PR, which in fact was exactly what i have been told to do by @radare and does not contribute anything to the fact how to fix it for all use cases
Okay, I will try to solve this problem once for all then. But, please, calm down.
See #9 ! But, removing the last commit and applying what said pancake is simpler (imho).
Should be fixed now