|Re: [hatari-devel] Bug: cart_asm.s Pexec() implementation overwrites basepage command line end|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Am Thu, 8 Nov 2012 16:43:40 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> On torstai 08 marraskuu 2012, Eero Tamminen wrote:
> > 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?
I didn't write that code, I just changed it countless times ;-)
It's still based on the original WinSTon code (which borrowed it from
STonX if I remember clearly).
> The problem is pretty obvious (comments marked with "<-"):
> move.l d0,d6
> move.l a5,-(sp) <- basepage address
> add.l #228,(sp) <- *adds 228 to it, not e.g. 256*
That's of course bad ...
> I think simplest would be just to add $1C to both of these offsets
> and the offsets used by the code setting up the bss/data/text values
> later on to the basepage.
That won't work since a lot of programs are expecting that the basepage
is 256 bytes right before the text segment.
> However, real TOS seems to be putting text section right after
> basepage like the above code does (to save 28 bytes of RAM I guess),
> so probably for compatibility cart code should do the same. E.g.
> load the header to basepage+256, but copy the values to safety
> (regs or vars) before reading rest of the file to the same position.
I think the best solution would be to have a look at EmUTOS to see how
Pexec loads the program segments there (and that's most likely also
what the original TOS is doing). I slightly remember that there was also
a difference when a program contains a section with debug symbols...
original TOS does not load them, but AFAIK the cartridge code does.
That caused some problems that we worked around in the past, but
maybe they could also have been avoided by simply doing it the same way
as (Emu-)TOS does.
I'm not sure when I'll got some spare time to work on this issue, so
Eero, do you feel confident enough to fix this on your own?