r2ghidra doesn't work with radare 5.0.0

Question

r2ghidra doesn't work with radare 5.0.0

Closed this issue 4 years ago · 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

Answer 1 · 2020-12-23T13:24:28.000Z

i can reproduce this issue. it's not a bug in r2. thanks for reporting, i'm taking care of it

Answer 2 · 2020-12-23T14:32:03.000Z

I did a workaround in the r2pm package. Ill do the proper fix when i find some spare time

Answer 3 · 2020-12-23T17:58:23.000Z

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

Answer 4 · 2020-12-23T21:28:25.000Z

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!

Answer 5 · 2021-01-14T13:17:59.000Z

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).

Answer 6 · 2021-01-14T14:30:32.000Z

Yep i also have the same problem, and this was introduced in this commit #8

Answer 7 · 2021-01-14T15:07:12.000Z

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?

Answer 8 · 2021-01-14T15:13:12.000Z

For the others, a simple workaround would be to drop the very last commit.

Answer 9 · 2021-01-14T16:05:57.000Z

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.

Answer 10 · 2021-01-14T20:39:05.000Z

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)

Answer 11 · 2021-01-14T22:03:12.000Z

Same Issue! with 5.0.1 too....

Answer 12 · 2021-01-15T17:20:07.000Z

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.

Answer 13 · 2021-01-15T17:27:56.000Z

@perror how exactly would that help to get a functional distro package?

Answer 14 · 2021-01-15T17:30:00.000Z

It will remove the last commit which is messing up everything.

Answer 15 · 2021-01-15T17:35:16.000Z

@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.

Answer 16 · 2021-01-15T17:41:14.000Z

@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.

Answer 17 · 2021-01-15T17:45:01.000Z

@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.

Answer 18 · 2021-01-15T17:59:19.000Z

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

Answer 19 · 2021-01-15T18:03:54.000Z

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.

Answer 20 · 2021-01-15T18:11:43.000Z

Then, I should as well repeat myself again and say that your last PR is just preventing r2ghidra to build properly...

Answer 21 · 2021-01-15T18:12:43.000Z

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

Answer 22 · 2021-01-15T18:23:48.000Z

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.

Answer 23 · 2021-01-15T18:27:49.000Z

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

Answer 24 · 2021-01-15T18:36:58.000Z

Okay, I will try to solve this problem once for all then. But, please, calm down.

Answer 25 · 2021-01-15T22:48:09.000Z

See #9 ! But, removing the last commit and applying what said pancake is simpler (imho).

Answer 26 · 2021-01-16T03:19:31.000Z

Should be fixed now