built-in rom crashes client and host on shrinkler-packed executables
 

While trying to run octorubber (or other demos packed with same packer), on a4000 default config, with the replacement rom, the amiga-side emulator crashes, and then the host system crashes.

Repro steps:
1. WinUAE 3.2.2 (I used a clean download)
2. quickstart a4000 config - no roms
3. add dh0 as an empty folder
4. put octorubber in the folder (http://www.pouet.net/prod.php?which=64249 -> download -> unpack it)
5. boot the emulator
6. launch octorubber from the CLI

Repro rate 100% (5/5 attempts)

Note: I have done the same with an executable I shrinkler-packed - same crash. If I didn't shrinkler-pack my executable, it didn't crash.
This repros in 3.0.0 as well.

Note: With a tweaked configurations, the WinUAE host does not crash, but the demo just never launches. In the debugger I see the program counter is in some weird address in not real memory. I suspect there are 2 bugs here:
1. the built-in replacement ROM doesn't properly launch Shrinkler-packed executables because of Shrinkler's assumptions about registers ("Your Amiga program just did something terribly stupid" in the log). This seems like a compatibility bug and was reported on aros-exec.org.
2. WinUAE (host side) crashes as a side effect of this.


Note from the author of Shrinkler about the AROS rom: "my guess is it leaves registers in a different state than the AmigaOS launcher. Shrinkler assumes that A3 points to the loaded segment list (4 bytes before the entry point) which is true for all Amiga kickstarts but might not be for AROS.

If A3 points to garbage, it could give the behavior you describe"

Hmm.. Looks like A3 pointing to seglist is just a randomly chosen temp register used as a jump address and application imho shouldn't assume it containing anything useful.

Contents of A2, A5 and A6 and others are side-effect of BCPL calling convention and they need to be exactly correct but A3 is more or less a BCPL scratch register.

Anyway, it can be "fixed"..

Heh, it isn't the first time an undocumented side effect became a useful feature :-)
Since it is consistent across all kickstarts, i can understand why the author took advantage of it.
I think fixing the actual host-side crash is also important - not just make the rom emulate the a3 behavior (which will probably mask the crash)

Thank you for looking at this. I am always impressed by your dedication and quick responses.

"Fix" committed but I am not yet sure when I'll update built-in ROM. There has been some endian problems and other changes that only affect m68k and I am not sure if they are all fixed.

Thank you :-)

what problems do you mean?

if you want to check tonis changes immediately, then use the roms from aros tomorrows nightly instead of the built in one.