On Fri, Apr 26, 2019, at 10:39, Jeremy O'Brien wrote: > On 2019/04/26 07:44, Remi Pointel wrote: > > Hi, > > > > attached is the port of ghidra: a software reverse engineering (SRE) > > framework. > > > > ---------------- > > $ pkg_info ghidra > > Information for inst:ghidra-9.0.2 > > > > Comment: > > software reverse engineering (SRE) framework > > > > Description: > > hidra is a software reverse engineering (SRE) framework created and > > maintained > > by the National Security Agency Research Directorate. This framework > > includes a > > suite of full-featured, high-end software analysis tools that enable users > > to > > analyze compiled code on a variety of platforms. Capabilities include > > disassembly, assembly, decompilation, graphing, and scripting, along with > > hundreds of other features. Ghidra supports a wide variety of processor > > instruction sets and executable formats and can be run in both > > user-interactive > > and automated modes. Users may also develop their own Ghidra plug-in > > components > > and/or scripts using Java or Python. > > > > Maintainer: Remi Pointel <rpoin...@openbsd.org> > > > > WWW: https://www.ghidra-sre.org/ > > ---------------- > > > > Ok? > > > > Cheers, > > > > Remi. > > Nice. You may be interested in my (pending) MR to ghidra which also > adds support for compiling the native components (decompiler, > demangler): > > https://github.com/NationalSecurityAgency/ghidra/pull/490 > >
I noticed this port was committed today. I have to ask, did you actually try to use it? In its current state, (sans my above changes), there is no decompiler nor symbol demangler. This might have been OK to omit, except for the fact that you will get a "Could not find decompiler executable decompile" popup every single time you click anywhere in the disassembly pane, which makes this port unusable. See below screenshot: https://pintobyte.com/tmp/ghidra_decompiler_error.png
