Closed red-llama closed 5 years ago
As a test on your processor I took this manually disassembled game for comparison https://github.com/gnaghi/SMWDisC
Overall things look great but the JSR problems are still present. Namely the first three JSR instructions refused to disassemble even after checking the processor state registers. I checked the application.log and don't see any issues standing out. Let me know if more information is needed.
@zamboni33 open the file you're analysing and go to the code listing. Put the cursor at the start of the JSR instruction. Then open the script manager, the sleigh
group, and run the DebugSleighInstructionParse
script. Copy-paste the output and I'll try to see what's going on.
This script is awesome. Thanks for the heads up.
Instruction: 0x20 0xe8 0x80 Output: Successfully compiled: DebugSleighInstructionParse.java DebugSleighInstructionParse.java> Running... DebugSleighInstructionParse.java> NOTE: bitrange's number leftmost/most-significant bit as 0 (zero). This bit numbering agrees with the context field specification but differs from token field specification. The bit correspondence for token fields depends upon the specific token size/endianess and current byte-offset of pattern matcher.
initial context bits: 11000000.00000000.00000000.00000000
resolving constructor for instruction bytes at: bus:008052
decide on instruction bits: byte-offset=0, bitrange=(0,7), value=0x20, bytes=(00100000)
decendent constructors for decision node (complete tree dump ordered by line number):
: {line# 801} JSR
Prototype parse failed: Unable to resolve constructor at 008052 DebugSleighInstructionParse.java> Finished!
@zamboni33 hmm, your output looks different to what I get when I try to reproduce to bug with your instruction bytes. Can you double check that you're using the latest version of the plugin and have restarted Ghidra? Also, if you disassembled the instruction with an older version of the plugin, I think you have to clear the disassembly for those bytes and re-disassemble them -- I think Ghidra won't automatically re-analyse anything just because the plugin changed.
The fix worked correctly for me. Thanks!
achan1989,
Can you please send me some steps on disassembling the bytes from my error log up above? I put those bytes by themselves into a file and threw it into ghidra but it can never disassemble them. Let me know what your processor bits are so I am not re-creating it incorrectly.
What I did: I removed my 65816 folder and un-tarred the second release again into Ghidra/Processors as 65816. I loaded in a file with the three bytes 0x20e880. I reset the processor bits EF, XF, and MF to 0 and attempted to disassemble. I have a bookmark "Unable to resolve constructor".
The sequence 20 xx xx (JSR) is not dissasembled correctly.
The tooltip for the error icons reads:
Error [Bad Instruction] Unable to resolve constructor at address
Using patch instruction to try to enter the instruction manually inserts 20 20 xx xx into the disassembly.