Unsuccessful MIPS decompilation

[erorcun]

Hi, I've just discovered the tool and wanted to test it with some MIPS executable I have, but it seems decompilation being cut at some opcode (output is only ~5 lines) but the tool acts as it decompiled the whole function, without any error messages.

I've tried it within IDA and without it, but always with --select-decode-only and --select-range options. Also tried to shrink function end address gradually to see where's the problem, but I haven't had any luck.

I can send the binary file and range to any team member e-mail.

Thanks.

[erorcun]

Why no team member replies to me?!

[pfalcon]

Why no team member replies to me?!

You may help the team by including number of your paid support contract, they must have forgotten it ;-)

[xkubov]

Hi @erorcun. Sorry for the inconvenience. You can send the binary file privately to my email address ([email protected]) and I (or someone from the team) will take a look at your issue.

[xkubov]

Hi, I've received your file and looked into the issue. After I've run retdec-decompiler.py with the provided file, decompilation failed in debug mode on following assertion:

retdec-bin2llvmir: src/llvm-project/lib/IR/Instructions.cpp:2157: void llvm::BinaryOperator::AssertOK(): Assertion `getType()->isIntOrIntVectorTy() && "Tried to create a logical operation on a non-integral type!"' failed.
Error: Decompilation to LLVM IR failed

I've debugged the source of this issue and managed to find a bug in translating module capstone2llvmir. Specifically, a bug in the work with MSA (MIPS SIMD arch.) registers during LLVM IR creation.

Little intro:
MIPS SIMD documentation tells that size of registers w0-w31 is 128 bits and each one of them can be viewed (depending on the instruction) as:

• 16 x 8bit elements
• 8 x 16bit elements
• 4 x 32bit elements
• 2 x 64bit elements

Type of elements can be integer, fixed-point or floating-point.

In RetDec is each MSA register implemented as 128-bit float and each instruction that works with such registers is required to extract required part of the register and cast it to the appropriate type (according to particular instruction) to create work with it.

Back to the issue:
As the binary file is translated into LLVM IR, the decoder uses Capstone to decode instruction opcode. As decompilation of the provided file progressed, the decoder found instruction ORI on address 0x26737c and decoded that operands of this instruction are: $w31, $w31, 0xb7. In the current implementation of the translation of the instruction ORI into LLVM IR, it is not expected to find work with operands of non-integer type (w31 is 128-bit float) and LLVM IR generation fails on invalid operands for integer instruction OR.

I managed to fix this bug by casting f128 operands to i128 after which decompilation finished without a further problem. Before opening a pull request, however, I need to take a look at the implementation of other MIPS instructions too as this problem affects all instructions which operands can be MSA registers.

[erorcun]

Awesome! Thanks for the description and quick fix!

[erorcun]

Hi, I'm sorry but this issue still persists. Yes, now I can decompile the file without IDA plugin, but that particular function I indicated from e-mail are still not being decompiled. Have you tried the file I sent you after the fix is merged?

[s3rvac]

@PeterMatula and @xkubov: Could you please take a look at the binary @erorcun has sent to you (see this comment)?