mumbel/ghidra_i960

Compare and branch src1 not disassembling correctly.

Closed this issue ยท 2 comments

Using Ghidra 9.1.2, when the data disassembles as cmpib or cmpob the src1 value is incorrect. The src1 value displays bits 4-0 instead of bits 23-19.

As an example, highlighted in green I have 00070978 10 20 2d 3d cmpibne 0x10,g4,LAB_00070988
image
But I know that it should be cmpibne 0x5,g4,LAB_00070988 instead because the game is looking to compare the value of 5 and bits 23-19 match up correctly. This was also true in other instances and not just this one.

Looking at the scrape.py file, it shows this structure commented for COBR so I'm not sure what's causing the issue.
image

@egregiousguy Thanks. wow... that's an interesting find, super surprised I never caught that. bbc, bbs cmpob*, and cmpib* would have all been affected, so hopefully those look better and not worse. I did verify you're correct for these 4 bytes in objdump and this now reports the same in ghidra.

d3ff54a Should address the problem, feel free to re-open if this still isn't looking right

@egregiousguy / @cglmrfreeman It just clicked reading this again and seeing my README.md. There is nothing in the module stopping you from using any version of ghidra, I just wrote the README.md at the time of 9.1.2 and really should have made it more generic. You can use current or any version for that matter. The disassembly wont change, but analysis (decompiler) and performance will likely improve on newer builds.