Gregory Morse

There is likely a bug in the interface. The protocol is complicated enough as well as IDAs database information to make the whole thing non-trivial. Usually the best option is...

Sorry I meant Ctrl+G. The exception is not helpful, but did you get a stacktrace? The stacktrace is the key. Its probably a bug you found, some error or protocol...

That offset is >>> hex(14757395258967641292) '0xcccccccccccccccc' All 'c's is usually in a debug build for uninitialized memory. But its an infinite recursion that is causing the issues. Line 900 ->...

Line 976 should change `(!checkPointer(offset, typeChain, deps))` to pass an extra parameter, bool dataChecked. Then on line 900 it should do `if (!dataChecked) lookupData()`... Such an infinite recursion should not...

Yes I had planned on fixing the cmake environment to have proper downloading of a customizable version of Ghidra sources, right now it hard codes the v1.0 sources that I...

PropertySheet.props contains custom configuration for Visual Studio building, and MakeGhidraDec.bat has the path of CMake and win_flex_bison also required for packaging with this script. I need to update the readme...

It has not been tested with 10.1.5 but if anything in the protocol changed, or if any bug in handling various complicated parts of the protocol between the decompiler and...

It requires PRINT_DEBUG to be defined when compiling due to the logging to fixed paths in: https://github.com/GregoryMorse/GhidraDec/blob/master/decompiler.cpp Really the path for the logfiles should be on the GUI, and if...

This is a flaw in the Java frontend only, not the back end as pointed out. The decompiler just expects the stack locations to be correct. __pascal is __stdcall with...

The backend does not really care much about the order. Its only a display issue. So the XML would be identical for stdcall. Underneath the hood the stack offsets are...