Ghidra: Decompilation broken for MIPS:BE:32:default

[zeroKilo]

Describe the bug
Decompilation fails with error
Low-level Error: Could not find op at target address:

To Reproduce

1. have MIPS:BE:32:default asm
2. opcodes clearly gets disassembled
3. functions are found, but
4. on decompilation it fails with above mentioned message

Screenshots

Environment:

• OS: Win7
• Java Version: 12.0.2
• Ghidra Version: 9.1-BETA

Additional context
I have developed a loader for N64 Roms and want to upgrade it for ghidra 9.1 (the code in that repo was already upgraded for 9.1 but the dist was left for 9.0.4)

[emteere]

Can you post the decompile debug .xml output file for this function? The issue may not be at the instruction, as I can't duplicate the issue with a similar set of instructions.

[zeroKilo]

Sure, here 4 examples
debug.zip

[yaz0r]

For what it's worth, I'm seeing the same issue with the SH2 processor and 9.1-Beta, so probably not CPU related.
This is from a database upgraded from 9.0.4 and I'm also using a bunch of overlays. Let me know if you need extra info.

[emteere]

Possilbe overlay related. It may be related to the new syscalls features, or the upgrade from 9.0.4.

[emteere]

@zeroKilo are any of your memory blocks overlays?

Also very strange your debug xml dumps don't have the entire set of bytes for each function.
Can you copy and paste the byte string for the function at 800007ec?

Is the memory block containing 0xa00007ec actually an overlay on top of some other memory block, or is another memory block overlayed on this one?

[zeroKilo]

well im not sure what you mean by overlayed. I create an InputStream for most blocks from a single byte[] array, the rom, and the 2 .spXXX blocks that are zeroed byte arrays. these blocks dont overlap in memory, the layout is like following:

here the bytestring of fun_800007ec
here the disassembly of fun_800007ec
here the actual rom file
here the function making blocks
here is how the makeblock function is used

[yaz0r]

I reproduced the issue on my end with a clean new project in 9.1-dev and 2 segments (still with SH2)
Should I just attach the .gar file here? (1.7mb)

[emteere]

This is definitely an issue with overlays. Your second parameter to MemoryBlockUtil.createInitialedBlock is actually creating an overlay block. You should pass false there, and your issue should go away.

There appears to be a lookup issue with the decompiler and overlays, possibly associated with the new reference overrides for syscalls.

[zeroKilo]

yes you seem to be right, changing the second parameter to false lets the decompilation finish

is there anywhere to read about what overlays mean? I still dont understand the difference, whats it used for normally?

[yaz0r]

@zeroKilo overlays are used when you have multiple code segments that can be loaded at the same address in memory. Their address would overlap in memory, so you need to create them a separate overlays.

The root issue remains, as overlays are basically unusable in 9.1 due to this.

[emteere]

Agreed. The overlay issue is a regression related to system call override changes, it is being diagnosed and will be fixed before release.

[zeroKilo]

@yaz0r thanks for the explanation

[yaz0r]

I would hardly call this issue resolved. @emteere do you need a new issue to track the overlay problem or want to reopen this?

[ryanmkurtz]

Fixed by bf4a17b67dff93b6a2555ceb4eed9ba85d019e05