-m68040 compiler option leads to crashes

[autc04]

I've heard that https://github.com/antscode/MacHTTP crashes when -m68040 is added to the compiler flags.

[autc04]

(reported by @antscode)

[cy384]

I get crashes on -march=68020 while running 68k under Mac OS 9 on qemu PPC, possibly the same issue? Unimplemented instruction error on a "DC.W".

macsbug screenshot attached

edit: and when compiled with -march=68040, same conditions, macsbug:

edit 2:
plot twist: if I compile with -march=68040 and without "-O2", my program runs almost to the end before crashing (similar error as the second screenshot)

[cy384]

so I spent the night digging into this a little, compiling all my libraries and my main binary with "-march=68020 -O2", since without optimizations my program is not usable on 68k machines

I'm using mbedtls and libssh2, which are both designed to be very portable, and use a somewhat complicated system of macros and function pointers to wrap free and malloc

replacing all of the 'obfuscated' calls with actual simple free/malloc calls seems to fix all the crashes

[autc04]

Cool!

I've never really used those libs myself, can you provide some hints on what the minimal setup is to reproduce the problem? I've never really debugged this properly because setting up the whole thing didn't feel like it was my idea of fun :-)

[cy384]

sure, I'll write up a minimal program that can call mbedtls and crash, and some build instructions

[cy384]

so I haven't managed to get a simple reproduction without building my whole app with multiple libraries, but I've found some things:

• mbedtls has a config option where it only uses stack memory and does no mallocs/frees, and enabling that results in all mbedtls code working without errors (not surprising I guess)

• further into my program, libssh2 gives errors that malloc is returning null pointers (and mbedtls doesn't seem to check for null pointers as much, so maybe that was also a problem)

• increasing the memory in the get info box doesn't change anything

edit: so after the malloc fails, I tried a NewPtr() and a MemError(), and I get a -113 memAZErr, no idea what that means... maybe I should actually read IM: Memory.

[autc04]

OK memAZErr sounds like heap corruption... Apparenty, if a bus error happens in the Memory Manager during some operations, that is caught and reported as an error instead of just crashing.
At least that's what I got from https://www.fenestrated.net/mac/mirrors/Apple%20Technotes%20(As%20of%202002)/me/me_14.html - that points to other reasons for the problem there, but those are all about bad 80's mac-specific practices, so I'm pretty sure that libssh/mbedtls don't do that, so heap corruption is the only explanation I can think of. Unfortunately, that could come from anywhere.

It does look like I'll have the time to play around with this in the next few days.

[autc04]

I now managed to set everything up, compiled everything for 68000 and only mbedtls for 020, and got a crash when I type exit.

It looks like it is indeed a compiler problem, looks like some references to the standard libraries are resolved incorrectly for 68020 code, causing a call to free to end up in the wrong place. But I'll need to investigate some more...

[autc04]

I just enjoyed a crash-free ssheven session now :-)
I still need to clean up a bit and maybe fix some collateral damage, so my fix is in a branch for now, the r_68k_pc32 branch. Please give it a spin.
(To test quickly, run make install in both the build-target and build-host directories, then rebuild ssheven)

For the record:
The problem was that the R_68K_PC32 relocation, i.e. support for instructions with 32-bit PC-relative offsets, was missing. If one of these instructions was used for a function call between different CODE segments, the jump ended up in the wrong place.

The instruction in question is the BRA.L instruction, which is quite rare as it is only used when tail call optimization applies, so things seemed to mostly work until a function named aes_ctx_free made a tail call to the standard library free function (which is in a different code segment).

[cy384]

fantastic, it's working great for me

this is so helpful, thanks a ton!