SheepShaver: Requirements for rebuilding precompiled dyngen?

[rakslice]

I set out to do an --enable-addressing=direct build of SheepShaver in Linux, for use in situations where the kernel tunable mmap_min_addr is not accessible. But of course the precompiled dyngen captures its configuration of real addressing, and will not do.

What OS and version was used to build the precompiled dyngen headers at https://github.com/cebix/macemu/tree/master/SheepShaver/src/Unix/dyngen_precompiled ?

It would save some time hunting and wrangling old distros if someone knows this.

[rakslice]

For future ref, Debian 6 x86_64's gcc 4.4.5 has worked for me with other branches and would at least be a good starting point in a search for what created the exact code that is checked in in the *-dyngen-ops-x86_64.hpp versions

[rakslice]

Hey @asvitkine , in https://github.com/cebix/macemu/commit/5538376dc8dfe8025eee3e0ad83635fc20dd11db you added the things in https://github.com/cebix/macemu/tree/master/SheepShaver/src/Unix/dyngen_precompiled. You mention they were built with gcc. Do you remember what version of gcc it was or maybe what it was part of?

I want to rebuild with direct addressing mode, but was hoping to be able to do an exact rebuild with real addressing mode first as a starting point to make sure my setup is not different in some way that matters to the output.

[rickyzhang82]

In BII, you need to disable GCC optimization because I found that the generated assembly code is ud2 when playing with NULL pointer.

See here

[rakslice]

@rickyzhang82 This issue is specifically about SheepShaver; the dyngen and saved pregenerated output of it, is only used for SheepShaver. To be honest I haven't studied the JIT for BII much at all as I'm using its JIT in direct mode already in Linux and haven't had any problem with it :D

I see what you mean about the problem with this check when building BII in real mode. Is there an open issue for that?

[rakslice]

Never mind, I'll just open one and if it's a duplicate we can sort it out later :D

[rakslice]

231

[SegHaxx]

Well I dug into the origin of this code. Looks like Gwenole wrote it in 2003: https://sourceforge.net/p/basilisk/mailman/message/2164955/

And Gwenole says they use GCC 3.2.2 on x86 and GCC 3.3.2 on x86_64 here circa 2004: https://sourceforge.net/p/basilisk/mailman/message/2165265/

You may want to try all the way back to GCC 2.95. 3.x was an era of chaos and breakage in GCC.

Also this seems to derive from qemu? Can we pick newer code out of qemu perhaps?

[rakslice]

Like if you want to port SheepShaver to TCG, no one's gonna say no 😃

[rakslice]

As far as what versions of gcc the dyngen historically is expected to work with, it's basically all right there in configure.ac up to and including 3.x: yes anything later than that: no

But obviously the compiler this question is about produced x86_64 output, it couldn't be GCC 2.95 could it? 😄

[rakslice]

If I was trying to use newer CPU emulation out of QEMU, the first thing I would do would be to see about the shape of Unicorn Engine https://github.com/unicorn-engine/unicorn, a project basically trying to be a portable version of just the CPU emulation from QEMU

[rakslice]

Because of the nature of what is happening in the dyngen approach, and moreover just the age of the codebase, it is going to be sensitive to compiler breakages that are not really on gcc's radar involving code that is perfectly valid but so unlikely to be the way someone would do something today that it probably fairly just never gets tested. For instance the inline x86/x86_64 assembly version of SheepShaver's op_mulhw_T0_T1:

asm ("imul %0" : "+d" (T0): "a" (T1));

worked in gcc 6, was broken for two entire major versions (7 & 8) and then fixed again in gcc 9.

(Compiler explorer: https://gcc.godbolt.org/z/r8hj7W)

[rakslice]

And that's inline assembly, it technically isn't even compiling it 😉

[rakslice]

(That's sort of a joke, it probably actually took all of the optimization rules it could muster to mistakenly elide the copying of the result to the output register)

[rakslice]

All that is to say, if someone got this working in the Xcode 8 era, I expect they may have done so with a very special compiler version in addition to whatever compiler flags they might have temporarily changed

[rakslice]

Don't even worry about it.