Skip to content

m68k: jsr (sp) doesn't work as expected

Description of problem

Consider the following code (disassembly from ghidra). This copies the current SP to A1 then copies 0x68 bytes from the address pointed at by A0 to the address pointed at by A1 with increment. This should end up with a copy of some bytes and SP pointing at the first.

        ff8241e6 22 4f           movea.l    SP,A1
        ff8241e8 70 68           moveq      #0x68,D0
                             LAB_ff8241ea                                    XREF[1]:     ff8241ee(j)  
        ff8241ea 12 d8           move.b     (A0)+,(A1)+
        ff8241ec 53 80           subq.l     #0x1,D0
        ff8241ee 66 fa           bne.b      LAB_ff8241ea
        ff8241f0 4e 97           jsr        (SP)

SP is 0x3bfc at the jsr so we'd expect to jump to 0x3bfc and put the address to return to at 0x3bf8 so the jsr can return I think? What currently happens in QEMU is the return address is put at 0xb3f8 and PC also becomes 0x3bf8 and the return address starts being executed as code and things go off the rails.

Forgive the screenshot but this is what it looks like with GDB connected. Dumping the memory where the PC is shows that the return address is actually there and we can see there is garbage before the instructions it should be executing.

image

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information