Re: [MiNT] Pexec(), basepage and command line handling?

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

You can ignore this.  It seems that Hatari has some
bug in its GEMDOS HD emulation Pexec() support.

Test program works fine from floppy and HD images.


	 - Eero

On torstai 08 marraskuu 2012, Eero Tamminen wrote:
> 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(), all the TOS versions seem
> to read the program file to position basepage + 228 bytes
> (at least with the attached 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 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 tracing what happens at GEMDOS level (with Hatari):
> -------
> 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 TOS 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 that same seems to happen
> with all TOS versions (including EmuTOS).
> 
> 
> Could somebody explain why this happens?
> 
> 
> 	- Eero
> 
> PS. This issue came from Frank Wille, VBCC C-compiler 68k backend
> maintainer, who was looking into adding TOS support to VBCC.
> 
> I think currently MiNT VBCC is compiled with gcc/MiNTlib, but
> Frank would like the compiler to be self-hosting (and MiNTlib
> license situation seems a bit of a mess).