I'm trying to disassemble some 6502 using Ghidra. The following (prerequisites: POSIX-style shell, Python 2.x) will generate a file called
test.dat that demonstrates the issue:
python -c "open('test.dat','wb').write(''.join([chr(x) for x in [0xa2,0xa3,0xa9,0x00,0x9d,0x40,0x00,0xca,0x10,0xfa,0x60]]))"
Then, from in Ghidra:
- create new project (wherever you like)
test.datcreated above, with Language as
Base Addressas 0x400
- double click
Active Projectto get to the CodeBrowser window
- say No when analysis is offered
- go to location $400 and press D to disassemble
The disassembly is pretty short.
// // RAM // fileOffset=0, length=11 // RAM: 0400-040a // 0400 a2 a3 LDX #0xa3 0402 a9 00 LDA #0x0 LAB_0404 XREF: 0408(j) 0404 9d 40 00 STA $0x40,X=>DAT_00e3 = ?? 0407 ca DEX 0408 10 fa BPL LAB_0404 040a 60 RTS
The odd thing here is that rather than generating a label for
$0040, which is the base address of the table, it's generated one for
$00e3 - the first byte accessed - as if X is a TOC pointer, or similar, and $0040 is the offset. This isn't appropriate for 6502 code.
In this little example I can right click and fix up the references by hand, but I don't mind admitting that I don't want to have to do this for an entire program. 6502 code is full of this stuff.
Can I stop this from happening?
(I got very lost trying to follow through the Java source provided! - but I did figure out that this sort of reference is known as an extended reference, and appears to be common to all targets. I couldn't find anything in the documentation about these, though, or how to disable them.)