[hatari-devel] Bug: Hatari GEMDOS emulation Pexec() overwrites part of created basepage

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

Here's a Hatari bug from Frank Wille (VBCC 68k backend maintainer)
which I debugged...

In short, under GEMDOS HD emulation, Pexec() will overwrite
28 last bytes from the basebage with the loaded binary.
If program command line is >99 characters long, last
part of it will be garbage under GEMDOS HD emulation.

Problem happens also with Hatari v1.4, so it's pretty old.

I suspect that there's some bug in the cart_asm.s Pexec() wrapper.
Thomas, as you've written that, could you take a look at this?

This stops emulation before GEMDOS trap for Pexec() is entered:
	b GemdosOpcode = $4b


Details:

According to the documentation, basepage size is 256 bytes,
of which latter half, 128 bytes, is supposed to be reserved
for command line.  And of those 128 bytes 125 are actually
supposed to be usable for a command line:
http://toshyp.atari.org/en/005014.html#BASEPAGE
http://toshyp.atari.org/en/00500b.html#Pexec

However, when doing Pexec() under GEMDOS HD emulation,
all the TOS versions read the program file to position
basepage + 228 bytes (with the attached test program)
i.e. program data will overwrite end of the passed command
line starting at byte 100.

Attached is an test program (with AHCC project file) which
shows its args, and re-executes itself with a 119 chars long
command line.

The output from it under GEMDOS HD emulation is following:
-------
....
Giving myself command 119 chars long command line...
Loaded, press a key to execute.
Got command line args:
0: <>
1: <-bataritos>
2: <-tos-flags>
3: <7>
4: <-x>
5: <-Bstatic>
6: <-Cvbcc>
7: <-nostdlib>
8: <c:\vbcc\lib\startup.o>
9: <tmp1.o>
10: <-s>
11: <-Lc:\vbcc\l`>
12: <t>
13: <.>
14: <&>
-------

You can see that end of the command line has gotten overwritten
with "garbage".

When executed from a floppy:
        zip -r cmdlinetest.zip cmdlinetest/
        zip2st cmdlinetest.zip
        hatari cmdlinetest.st

or HD image:
        atari-hd-image 8 8mb-disk.img TEST cmdlinetest
        hatari --tos etos512k.img --acsi 8mb-disk.img

The output is fine:
-------
....
Giving myself command 119 chars long command line...
Loaded, press a key to execute.
Your system is too slow, some sound samples were not correctly emulated
Got command line args:
0: <>
1: <-bataritos>
2: <-tos-flags>
3: <7>
4: <-x>
5: <-Bstatic>
6: <-Cvbcc>
7: <-nostdlib>
8: <c:\vbcc\lib\startup.o>
9: <tmp1.o>
10: <-s>
11: <-Lc:\vbcc\lib>
12: <-lvc>
13: <-o>
14: <hello.tos>
-------


When tracing what happens at GEMDOS level under GEMDOS emulation:
-------
GEMDOS 0x4B Pexec(3, "SYSTEM.TTP", [119]"-bataritos -tos-flags 7 -x -Bstatic 
-Cvbcc -nostdlib c:\vbcc\lib\startup.o "tmp1.o"  -s -Lc:\vbcc\lib -lvc -o 
hello.tos", 0x0)
GEMDOS 0x2F Fgetdta()
GEMDOS 0x4E Fsfirst("SYSTEM.TTP", 0x17)
GEMDOS 0x4F Fsnext()
GEMDOS 0x4B Pexec(5, 0x0, 0x13c0e, 0x0)
GEMDOS 0x3D Fopen("SYSTEM.TTP", read-only)
-> FD 0 (read-only)
GEMDOS 0x3F Fread(64, 28, 0x1545c)
GEMDOS 0x3F Fread(64, 2147483647, 0x15478)
GEMDOS 0x3E Fclose(64)
GEMDOS 0x 9 Cconws(0x13BEB)
Loaded, press a key to execute.
GEMDOS 0x B Cconis()
GEMDOS 0x 1 Cconin()
GEMDOS 0x4B Pexec(4, 0x0, 0x15378, 0x0)
-------

One can see that program's Pexec(3) call is within EmuTOS implemented
using Pexec(5) to create a program basepage, and then loading of
the program binary.

You can also see that TOS does first Fread() to an address that is
offset 228 bytes from the returned basepage address that the program
gives to Pexec(4) after Pexec(3) has finished.

I've verified with a debugger that Pexec(5) actually returned
that address, i.e. program doesn't mangle the returned basepage
address, it's TOS itself that writes over the basepage it created
before returning from Pexec(3).


I've also checked with GEMDOS tracing when using GEMDOS emulation,
that *exactly* the same problem, at same offset, seems to happen
with all TOS versions, not just EmuTOS.  Which points againt to
Hatari bug.


	- Eero

Attachment: cmdlinetest.zip
Description: Zip archive