Update ghidra

[amibranch]

fixes #362

This pull request is based on my personal port from CMake to meson-build and updates Ghidra to Ghidra_11.4_build.
I do not consider that this is universally appreciated without further discussions. And even if so, it should not be done within updating the Ghidra base commit.

However, I personally prefer meson-builds dependency management over anything CMake or some CMake-related frameworks (like Conan) is offering. I think, that meson makes it easier to update and track Ghidra. I personlly think that this is als a nice improvement towards #322.

I was careful to separate my commits into exchanging CMake with meson and then updating Ghidra. Therefore, please feel free to reuse the commit of updating Ghidra for any own update that is based on the current build-system. Please note that this also implies that the patch-files (001_context_cache and 002_xml_format) should be carefully applied to rizins ghidra-fork

Note:

• Do not bother to apply the CI here without further changes. The meson-replacement did not yet contain changes to the CI files. I therefore do not expect any success...
• I only focused on updating the Ghidra base-commit and fixing any potential incompatibilities. There was no intention to implement support for any new feature the Ghidra decompiler provides with the update
• Tested on Arch Linux with rizin 0.8.1 @ linux-x86-64 and cutter 2.4.1-makepkg-a5f88d1
• You can either cherry-pick these changes to rz-ghidra, before Rename rz_list_first() to rz_list_first_val() #369 was merged and test it with a local installation (c.f. previous point) or build and test this against a local own installation/build of the current rizin dev-version

[notxvilka]

@amibranch since you are updating, why not use 12.0 version instead of 11.4 as a base? It was released few weeks ago and contains some nice changes in the decompiler code:

• https://github.com/NationalSecurityAgency/ghidra/releases/tag/Ghidra_12.0_build
• https://github.com/NationalSecurityAgency/ghidra/blob/Ghidra_12.0_build/Ghidra/Configurations/Public_Release/src/global/docs/WhatsNew.md
• https://github.com/NationalSecurityAgency/ghidra/commits/Ghidra_12.0_build/Ghidra/Features/Decompiler/src/decompile/cpp

[thestr4ng3r]

@amibranch Thank you for the proposal! However while meson certainly has certain advantages, I do not think think they justify the disruptive effects this would have downstream, or additional challenges such as missing direct access to the Cutter CMake module. So I don't think we are going to make this switch, at least for now.
As a sidenote, the most interesting change here imo is that the original ghidra repo is fetched and patched dynamically rather than needing another fork repo. This should also be doable in pure cmake (no conan, etc.) using ExternalProject/FetchContent as well. Whether that would be better is questionable too though, since it also affects distribution packaging and the development process.

Would you instead mind rebasing the https://github.com/rizinorg/ghidra repo, keeping the patch history as far as possible, and applying the rz-ghidra code changes as a new pr? If 12.0 has too many changes, doing the step to 11.4 only first would be fine for me too.

[amibranch]

@notxvilka : thank you for the hint. I started the change before that release. However, I will try to port the PR

@thestr4ng3r : Yes, I understand this and as I wrote, it was not my intention that the repo will port to meson build. Indeed in the first commit (before the ghidra-update), I used the rizin-port of ghidra via a meson-wrap file (which also worked well). Meson-wrap in that case is just an alternative for git submodules. I'm not too experienced with different dependency-managements in CMake.
However,...
Towards your question: yes of course, I can do this! However, it may take some days, as my priorities are at the moment:

• Creating a PR here
• Updating and testing this PR with Ghidra 12.0
• Then rebasing the Ghidra-changes to a newer Version and creating a PR on https://github.com/rizinorg/ghidra

Note: the additional changes in Ghidra pile down to remove "new" newlines in the XML-Encode. Those will bloat the generated code. I personally would even say that using a code-beautifier on the final code could be more consistent. But it is a more invasive change...

I hope this is clear, but if not: Please consider this PR as a "Draft" with no intention to merge!