Re: [MiNT] Corruption of high TPA

[Vincent Rivière <vincent.riviere@freesbee.fr>]

Vincent Rivière wrote:
> Konrad M. Kokoszkiewicz wrote :
> > Is memory protection enabled in your setup? If so, setting the sp at 
> > the end of the TPA will, IIRC, cause the program to crash at the 
> > nearest system call. This is so because the kernel entry code copies 
> > similar amount of bytes from the user stack to the supervisor stack. 
> > Because it does not know, how many bytes it should copy, it always 
> > copies the maximum amount, and there are kludges in the kernel to fix 
> > the sp at the correct value, when the program starts, but if you set 
> > it "manually", it will not work.
>
> Thanks for your hints.
>
> I have made further tests, this problem occurs only in ARAnyM + EmuTOS, 
> even on the EmuTOS early console. So it is unrelated to the MiNT kernel, 
>  AUTO folder, AES or accessories.

Hello, Konrad.

Finally, you were totally right !
I have been fooled because there was the same bug in the FreeMiNT kernel and 
in EmuTOS.

Thanks to Petr Stehlik and Thomas Huth, EmuTOS has been fixed yesterday.

Now about the FreeMiNT kernel. The problem becomes visible only when memory 
protection is enabled.

From sys/arch/syscall.S:
#ifdef NEW_SYSCALL
	move.w (a1),d1
	cmp.w	_dos_max,d1
	bcc	gemdos
// offset 0 is func pointer, 4 is nr of args, 6 is their size
nospr:	move.w	6(a5,d1.w*8),d1		// fetch size in bytes
	lsr.w	#1,d1			// we need size in words
cparg:	move.w	(a1,d1.w*2),-(sp)
	dbra.w	d1,cparg
#else
	move.l	32(a1),-(sp)		// a1 was set by build_context
	move.l	28(a1),-(sp)
	move.l	24(a1),-(sp)
	move.l	20(a1),-(sp)
	move.l	16(a1),-(sp)
	move.l	12(a1),-(sp)
	move.l	8(a1),-(sp)
	move.l	4(a1),-(sp)
	move.l	(a1),-(sp)
#endif

I guess NEW_SYSCALL is not currently used.
On every TRAP #1, 36 bytes are unconditionally read from the user stack. So 
when the user stack is at the very top of the TPA, this code tries to read 
the memory after the TPA, it is illegal and it crashes with memory 
protection. I'm "happy" to see that we encounter again the magical "36" 
value I found by experimental tests.

Is there a reason for not using that NEW_SYSCALL stuff ? It seems a lot cleaner.

I'm not going to change the kernel (but it should be done).

I will provide a patch for the MiNTLib as a workaround.

--
Vincent Rivière