Open philpem opened 1 month ago
This is a bug in https://github.com/NationalSecurityAgency/ghidra/blob/de7c3eaee2a4bc993a402e371b039c2bb2d6c545/Ghidra/Processors/MC6800/data/languages/6805.slaspec#L374 :
:JMP ADDRI is (op=0xDC | op=0xEC | op=0xFC) ... & ADDRI
{
goto [ADDRI];
}
The square brackets need to go:
:JMP ADDRI is (op=0xDC | op=0xEC | op=0xFC) ... & ADDRI
{
goto ADDRI;
}
There seems to be a similar bug in the indexed JSR instruction: https://github.com/NationalSecurityAgency/ghidra/blob/de7c3eaee2a4bc993a402e371b039c2bb2d6c545/Ghidra/Processors/MC6800/data/languages/6805.slaspec#L386
:JSR ADDRI is (op=0xDD | op=0xED | op=0xFD) ... & ADDRI
{
*:2 (SP-1) = inst_next;
SP=SP-2;
call [ADDRI];
}
I've synced to master and tried the PR out on my local build. While it seems to fix the references, it causes other issues:
1305 dc 13 16 JMP LAB_1316,X
instruction.DATA
reference in the References Editor - I think it should be COMPUTED_JUMP
(and for the JSR version it should be COMPUTED_CALL
).Low-level Error: Could not find op at target address: (unique,0x00000500)
.I don't think I'm doing anything wrong with the SLEIGH description, so this is puzzling. (though I'm used to the jump table detector missing jump tables)
The backtrace from the Stack analyser is:
Not a valid Address on instruction at 1305
ghidra.util.exception.AssertException: Not a valid Address on instruction at 1305
at ghidra.program.util.SymbolicPropogator.applyPcode(SymbolicPropogator.java:1047)
at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:529)
at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:425)
at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:179)
at ghidra.app.cmd.function.NewFunctionStackAnalysisCmd.createStackPointerVariables(NewFunctionStackAnalysisCmd.java:334)
at ghidra.app.cmd.function.NewFunctionStackAnalysisCmd.analyzeFunction(NewFunctionStackAnalysisCmd.java:185)
at ghidra.app.cmd.function.NewFunctionStackAnalysisCmd.applyTo(NewFunctionStackAnalysisCmd.java:113)
at ghidra.app.cmd.function.NewFunctionStackAnalysisCmd.applyTo(NewFunctionStackAnalysisCmd.java:41)
at ghidra.app.plugin.core.function.StackVariableAnalyzer.added(StackVariableAnalyzer.java:55)
at ghidra.app.plugin.core.analysis.AnalysisScheduler.runAnalyzer(AnalysisScheduler.java:186)
at ghidra.app.plugin.core.analysis.AnalysisTask.applyTo(AnalysisTask.java:37)
at ghidra.app.plugin.core.analysis.AnalysisTask.applyTo(AnalysisTask.java:24)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisTaskWrapper.run(AutoAnalysisManager.java:660)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:760)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:639)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:604)
at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:55)
at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:33)
at ghidra.framework.plugintool.mgr.ToolTaskManager.taskCompleted(ToolTaskManager.java:413)
at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:105)
at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:351)
at java.base/java.lang.Thread.run(Thread.java:1583)
---------------------------------------------------
Build Date: 2024-Oct-17 0022 BST
Ghidra Version: 11.3
Java Home: /usr/lib/jvm/java-21-openjdk-amd64
JVM Version: Ubuntu 21.0.4
OS: Linux 6.8.0-45-generic amd64
I get a similar error when I try to add a reference in the References Editor:
Not a valid Address on instruction at 1305
ghidra.util.exception.AssertException: Not a valid Address on instruction at 1305
at ghidra.program.util.SymbolicPropogator.applyPcode(SymbolicPropogator.java:1047)
at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:529)
at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:425)
at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:179)
at ghidra.app.cmd.function.CallDepthChangeInfo.followFlows(CallDepthChangeInfo.java:565)
at ghidra.app.cmd.function.CallDepthChangeInfo.initialize(CallDepthChangeInfo.java:154)
at ghidra.app.cmd.function.CallDepthChangeInfo.<init>(CallDepthChangeInfo.java:82)
at ghidra.app.plugin.core.references.EditStackReferencePanel.setOpIndex(EditStackReferencePanel.java:142)
at ghidra.app.plugin.core.references.EditStackReferencePanel.initialize(EditStackReferencePanel.java:116)
at ghidra.app.plugin.core.references.EditReferenceDialog.setAddOpIndex(EditReferenceDialog.java:192)
at ghidra.app.plugin.core.references.EditReferenceDialog.configureAddReference(EditReferenceDialog.java:261)
at ghidra.app.plugin.core.references.EditReferenceDialog.initDialog(EditReferenceDialog.java:249)
at ghidra.app.plugin.core.references.ReferencesPlugin.popupAddReferenceDialog(ReferencesPlugin.java:303)
at ghidra.app.plugin.core.references.EditReferencesProvider.addCallback(EditReferencesProvider.java:779)
at ghidra.app.plugin.core.references.EditReferencesProvider$2.actionPerformed(EditReferencesProvider.java:167)
at docking.DockingActionPerformer.lambda$perform$0(DockingActionPerformer.java:73)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
---------------------------------------------------
Build Date: 2024-Oct-17 0022 BST
Ghidra Version: 11.3
Java Home: /usr/lib/jvm/java-21-openjdk-amd64
JVM Version: Ubuntu 21.0.4
OS: Linux 6.8.0-45-generic amd64
Describe the bug Ghidra incorrectly interprets the JMP loc,X instruction as an indirected jump, when it is an indexed jump.
To Reproduce
For convenience, I've attached a Ghidra project archive: egret_2024_10_16.gar.zip
Disassemble the following block of code:
Initially Ghidra will disassemble this and mark the
0xCC
bytes as data.Select the JMP instruction and look at the matching code in the decompiler window. It will look like:
As Ghidra marks the first byte of the jump target as "case data" and marks the address 0xCC as "case code", it seems like Ghidra is misinterpreting the
JMP nnnn,X
instruction (opcode 0xDC) as if it were a hybrid of theJMP (nnnn,X)
andJMP (nn,X)
instructions -- in the sense that it reads the byte at the target, then jumps to it (an indirected jump), rather than jumping directly to the target.Expected behavior Ghidra interprets the code above correctly, and follows the jump instruction to one of the jump table entries, correctly identifying the code which is executed.
Environment (please complete the following information):