FYI, the problem appeared while trying to use a --gbaslot-rom=self with a romsize of 302254 (which I note to be not a multiple of 4). The crash occurs when a memcpy starts reading that byte-per-byte, with a position of 302251, where "pos + 4 > romsize" occurs first.
I'm afraid I cannot tell what real hardware would do then, because on real hardware, I have some DLDI code in the play. It could very well be that using memcpy to read from the GameInfo area is a mistake, and that e.g. only 4-bytes-aligned or 2-bytes-aligned reads are allowed. It could also be that my tools are incorrect and that producing a rom that isn't a multiple of (whatever) is a mistake.
I just fixed my problem by adding some unused bits at the end of the "embedded filesystem" area of my .nds file. Not very elegant, but it will do the trick for now.
Thanks for your help.
]]>ideally you would figure out what correct emulation should do, and fix it to do that instead of exit.
]]>Especially, before starting to hack the code by adding some calls to emu_halt here and there, I was looking for wisdom from The Builders about why there might be that third way. If i understand your check-one post correctly, there was no reason for not invoking something more elaborate than exit(), just that noone did it so far.
So, would there be a function name I should have a look at that could trap the GDB server instead of exit() ?
]]>I've seen other error condition that dumped some registers, and others that could be trapped with the GDB server embedded in the emulator. Nothing alike here? Just because noone has added it yet ? or is there any other reason ?
]]>