search

minimig-dev / MinimigAGA-MiST-TC64

Minimig for the MiST board
GNU General Public License v3.0
15 stars 8 forks source link

Aztec C 5.2 / Guru Meditation on Minimig #16

Open egrath opened 1 month ago

egrath commented 1 month ago

Hi,

Aztec C 5.2 produces a non recoverable Guru Meditation when running on Minimig with a code of 0x00000004 (illegal instruction). It makes no difference if running with different CPU settings.

Running Aztec with the same configuration (CPU, Chipset, RAM, ...) in any UAE works without problems.

For convenience reasons I packed all files needed to reproduce the issue into a archive and uploaded it to:

https://garm.twilightparadox.com/nextcloud/s/RPiYBB56t7fdBAo

The archive contains two HDFs with Workbench 1.3 (OS13.hdf), the Aztec C Compiler (OS13data.hdf) and a Kickstart 1.3 patched with scsi.device from 3.1 to allow booting from the IDE controller.

How to reproduce

  1. Use the mentioned HDFs in Minimig, then boot it with any settings like 68000 CPU, 512 KB chip memory, 4 MB fast memory.
  2. Open the CLI, and run: 
    execute data:aztec/aztec.sh
cc

    You will be greeted by a software failure message immediately, followed by a guru meditation.

Expected result Aztec C Compiler not crashing

Additional information The problem occurs in any version of MinimigAGA-MiST-TC64 tested (released version from the official MiST repository, master branch built by myself with Quartus)

robinsonb5 commented 1 month ago

Thanks for the report, and for the ready-to-go test rig. I've tested with both the original Minimig (which has a real 68000 CPU) and also the MiSTer Amiga core (using both TG68 and FX68) and it works fine on all three setups, so the problem is definitely specific to the MiST/TC64/SiDi128 core.

robinsonb5 commented 1 month ago

Interesting - whatever's causing this, it's related to the kickstart version. If I boot the same HDFs using Kickstart 2 or 3 there's no crash.

robinsonb5 commented 1 month ago

...and now I'm very confused! So I did some tracing of the CC executable in MonAm, and the crash is due to the _strncpy label pointing to the middle of another function, instead of the actual strncpy code. Which means either the execuable has been corrupted during loading, or the relocation process has failed.

Here's where it gets weird:

I tried the Minimig core on my old DE1 (a distant ancestor of the MiST Minimig core) and it's fine.

I tried the oldest MiST AGA core I could find, and it fails in the same way the current core does. (So whatever it is, it's not something recently introduced.)

(I also tried a pre-AGA MiST core, but the hard disk emulation seemed not to work with that - that's a side-quest I wasn't going to embark upon today.)

I tried a recent build on the TC64 (built from the same codebase as the MiST core) and it's fine.

I tried the current codebase (sidi128_drivesounds branch) built for DE10 lite and it's fine.

Since it doesn't appear to be a problem with the core (old versions also fail, new versions are OK on other platforms) the only common factor between the failing platforms is the ARM firmware - but I'm having a hard time imagining how that could be the cause. (There is a memory-detection patch which is applied on the fly when loading Kickstart 1.3 ROMs - I wondered if that was clashing with the custom ROM - but turning off the patch in a .ini file doesn't seem to make any difference.)