achan1989 / ghidra-65816

WDC 65816 processor module for Ghidra
MIT License
22 stars 3 forks source link

JSR instruction disassembly error #1

Closed red-llama closed 5 years ago

red-llama commented 5 years ago

The sequence 20 xx xx (JSR) is not dissasembled correctly.

image

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.

achan1989 commented 5 years ago

Thanks for reporting this issue. It should be fixed in v1.0.2

zamboni33 commented 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.

achan1989 commented 5 years ago

@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.

zamboni33 commented 5 years ago

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 : {line# 809} JSR decide on context bits: bitrange=(2,2), value=0x0, context=11(0)00000.00000000.00000000.00000000 decendent constructors for decision node (complete tree dump ordered by line number): : {line# 801} JSR check pattern[1 of 1]: {line# 801} JSR ( byte pattern: mask=11111111.00100011.00000000.00000000 bytes[0-3]=00100000.11101000.10000000.10011100 match-value=00100000.00100000.00000000.00000000 Matched ) -and- ( context pattern: mask=00100000.00000000.00000000.00000000 context(0..31)=11000000.00000000.00000000.00000000 match-value=00000000.00000000.00000000.00000000 Matched ctx_EF(2,2) == 0x0 Match ) Matched JSR_OP: resolving... decide on instruction bits: byte-offset=1, bitrange=(0,0), value=0x1, bytes=00100000.(1)1101000 decendent constructors for decision node (complete tree dump ordered by line number): JSR_OP: {line# 788} check pattern[1 of 1] JSR_OP: {line# 788} byte pattern: mask=11111111.00000000.00000000.00000000 bytes[1-4]=11101000.10000000.10011100.00000000 match-value=11111100.00000000.00000000.00000000 Failed Unable to resolve constructor

Prototype parse failed: Unable to resolve constructor at 008052 DebugSleighInstructionParse.java> Finished!

achan1989 commented 5 years ago

@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.

red-llama commented 5 years ago

The fix worked correctly for me. Thanks!

zamboni33 commented 5 years ago

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".