Re: [hatari-devel] Wrong stackframe for non-autovector IRQ and CPU >= 68020

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 5/5/19 3:34 PM, Christian Zietz wrote:
> Hatari (or rather the CPU emulation) puts a wrong exception frame on the
> stack for non-autovector interrupts (such as MFP, SCC) when a 68020 or
> higher CPU is selected. Steps to reproduce: Boot any TOS (that supports
> a 68020 or higher), break into the debugger and place a break point on
> the handler for MFP Timer C. The vector offset is 0x114:
>
> > m $114
> 00000114: 00 e0 08 b6 00 e0 0d 6c 00 e0 07 5a 00 e0 07 5a
> > a $e008b6
> > c
> [...]
> 1. CPU breakpoint condition(s) matched 1 times.
>          pc = $e008b6
> [...]
> > m "a7"
> m "a7"
> - 'a7' -> $a298
> 0000A298: 23 04 00 e1 fe c8 *00* *78* 00 00 01 8f 00 00 00 00
>
> The two bytes I marked with asterisks are supposed to contain the vector
> offset, i.e., 0x114, but the contain the offset to the auto-vector
> interrupt level 6 (0x078) instead.
>
> Interestingly, the stack frame is correct for 68010 CPUs or when I use a
> 68030 including MMU emulation.

I was hopeful that this would explain my crashes with Linux user
space programs, until I read that 030 + MMU should work correctly.

What I'm seeing is that Linux system calls (which are triggered
with an exception) don't always return with RTE, and eventually
one of the interrupt handlers gets called with an address that's
in middle of an instruction, not correctly aligned to it.


	- Eero