Debugging the native (C++) decompiler?

[mh-]

What steps do you recommend to activate the debugging code that's already in the C++ decompiler and apparently could write a debug log to a file (#define "CPUI_DEBUG")?
There's e.g. DecompileDebug.java and DebugDecompilerAction.java, but what's the best way to activate these?

[emteere]

You can activate the debug dump actions from the pull down menu at the top of the decompiler. They dump .xml files that describe all the input to the decompiler. Very useful for submitting a bug report as all the information necessary to re-produce the issue is included.
The other would be a compile time flag and I'd have to leave that to someone else to answer when and why you would want to use that.

[mh-]

I’m interested in the compile time flag. I want to use it for debugging the decompiler and/or my new processor definitions. I want to find out why the decompiler erroneously optimizes / deletes certain p-code instructions, until it believes that some code is unreachable (which is incorrect).

_{Sent with GitHawk}

[mh-]

I think the compile time flag is actually used to compile C++ code to ghi_dbg (in addition to ghi_opt); but what's the best way to activate the decompiler's "debug" code in ghi_dbg, as opposed to the "standard" code in ghi_opt?
And where can I then find the debug log (the stuff that's printed in the #ifdef CPUI_...blocks)?

I tried e.g. analyzeHeadless with LAUNCH_MODE=debug-suspend or debug, but didn't see any of the debug messages from the C++ code on the console, nor in the log file (./analyzeHeadless [...] -log ~/ghidra/projects/ghidra.log).

[bennofs]

@mh- ony way to debug the decompiler is using the integrated "dump debug info to xml" from Ghidra and then load the XML file into a command-line instance of the decompiler, like this:

$ export SLEIGHHOME=/path/to/ghidra/home
$ ./decomp_dbg # build this binary with make decomp_dbg
[decomp]> load function eval
Function eval: 0x00401186
[decomp]> decompile
Decompiling eval
Decompilation complete

Then you can easily modify the decompiler source / compiler flags and re-decompile the same function, or even attach a debugger like GDB to the decompiler directly.

[mh-]

Hi @bennofs , thanks a lot for your hint!
I was able to build decomp_dbg in ~/git/ghidra/Ghidra/Features/Decompiler/src/decompile/cpp after modifying the Makefile a bit and finding a libiberty and libintl for my Mac...

Since I didn't find any detailed instructions for the command line decompiler, I'll post my results here, hopefully this will help others...

$ export SLEIGHHOME=~/git/ghidra/
$ ./decomp_dbg
[decomp]> restore Reset.xml
Reset.xml successfully loaded: PIC-16(L)F153XX

(Reset.xml was generated using the little black triangle in Ghidra's Decompile window (--> "Debug Function Decompilation"), thanks to @emteere and @GhidraKnight for that hint. Either copy the .xml file to the directory where decomp_dbg is located, or specify the full path after "restore".)

[decomp]> load function Reset
Function Reset: 0x0000
[decomp]> decompile
Decompiling Reset
Decompilation complete
[decomp]> 

Now I can indeed debug the decompiler using gdb, or add printf() log statements to the C++ code (which will print to the console), or use the built-in functions with commands like

[decomp]> trace address 
OK (1 ranges)
[decomp]> trace list
Trace enabled (1 total ranges)
entire function 
[decomp]> decompile
Decompiling Reset
DEBUG 0: constbase
0x0000:39: **
   0x0000:39: BSR(0x0000:39) = #0x0:1
0x0000:3a: **
   0x0000:3a: PCLATH(0x0000:3a) = #0x0:1
(...)

The built-in commands can be found in ifacedecomp.cc

If there are public instructions available for this, I would be most interested :)

[astrelsky]

For anyone curious this works on windows using wsl without a problem. You just need to do export SLEIGHHOME=/mnt/c/path/to/ghidra/home since ghidra is likely in a windows directory.

[meromwolff]

Can someone share here what did they need to modify in the MakeFile? im trying to run it in windows (using wsl of course) and its not working...
Thanks!

[astrelsky]

Can someone share here what did they need to modify in the MakeFile? im trying to run it in windows (using wsl of course) and its not working...
Thanks!

I believe it originally worked out of the box. I attempted to recompile it from a out of data branch that built the last time I used it and ended up with:

In file included from loadimage_bfd.hh:24,
                 from bfd_arch.hh:22,
                 from bfd_arch.cc:18:
/usr/local/include/bfd.h:35:2: error: #error config.h must be included before this header
   35 | #error config.h must be included before this header

I can take a further look later this week if nobody else happens to do so.

[meromwolff]

I'm having a couple of errors concerning bison command - did you need to manually install that or something?

[astrelsky]

I'm having a couple of errors concerning bison command - did you need to manually install that or something?

Do you have it installed in windows? If not you shouldn't have to install it. Then again it may depend on which subsystem you're using. You could always just install it via apt

[saruman9]

I attempted to recompile it from a out of data branch that built the last time I used it and ended up with...

I solve the issue with a dirty hack: patch.

[beketata]

My working environment is Windows 7 64.
Is it possible to use some kind of IDE (Visual Studio for example) to debug ghidra c++ code?

[meromwolff]

So I successfully built the decomp_dbg but when I run the "restore" command, giving it the xml file I generated (using the "Debug Function Decompilation" button in the Decompiler"), the following error pops up: "Execution error: XML error parsing SLEIGH file: Unable to open xml document".
Im using Ghidra 9.2.

Thanks in advance.

P.S. needless to say I copied the xml file to the same directory of the decomp_dbg file.

[grant-h]

Same issue as @meromwolff ghidra 9.2

Edit: I figured it out with some GDB work. In a fresh git checkout of Ghidra, the SLEIGH spec files (.slaspec) are not compiled into the required .sla files. The loading will fail in SleighArchitecture::buildSpecFile when trying to find the slafile. Here's what I did to fix:

make sleigh_dbg
<make output>
./sleigh_dbg ~/ghidra/Ghidra/Processors/x86/data/languages/x86-64.slaspec
INFO    252 NOP constructors found
Use -n switch to list each individually
INFO    8 unnecessary extensions/truncations were converted to copies
Use -u switch to list each individually
INFO    13 operations wrote to temporaries that were not read
Use -t switch to list each individuall
./decomp_dbg
[decomp]> restore test_binary.xml
test_binary.xml successfully loaded: Intel/AMD 64-bit x86
[decomp]> load function entry
Function entry: 0x000100000f10
[decomp]> decompile
Decompiling entry
Decompilation complete

[meromwolff]

@grant-h
Nice work but actually my problem was that i didnt export the correct path for the SLEIGHHOME environment variable :)