-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change SheepShaver default build to direct addressing. #142
base: master
Are you sure you want to change the base?
Conversation
I'll note on both my current systems of interest, Debian aarch64 and CentOS 8 x86_64, I have tried to use the vm.mmap_min_addr=0 workaround, and have even booted CentOS 8 with SELinux entirely disabled, and still can not get mmap at 0x0 to work on these systems. It just doesn't work for me. Yeah JIT doesn't seem to work here but given it's a checkbox these days I don't see that it needs to be disabled at compile time. |
Do you really mean the actual mmap at 0 is failing? Or just that the build where that happens is crashing? |
I mean Linux will refuse to put the mapping at 0x0, and if you request 0x0 you will get back a random address higher in memory. Likely well past 32-bit addressing on 64bit platforms. |
As far as the crash during boot with x86_64 IIRC (somewhat more) alive forks and upstream also have that problem that x86_64 linux JIT on works and JIT off doesn't. |
The real addressing build I'm testing in x86_64 Linux is in Debian 9 running kernel 4.9.0-14. mmap of 0 must work there or else I'm really misunderstanding the situation? |
Well my Raspi4 is Debian 10.6. :) It seems to be a real recent change to disable the 0x0 mapping. I could maybe try firing up Debian 9 in a VM and see if that works. |
I've got a Centos 8 VM I've probably never used for this before, hold on gotta build SDL2 from source :/ |
Anyway, for the purpose of this particular pull request, making direct the default addressing mode, the issue I raised is that it makes builds that use the pregenerated JIT stuff that captures the real addressing mode configuration they were built with immediately crash which is not great in the default configuration. I assume rerolling the pregenerated JIT stuff for direct addressing is beyond the scope of the work you wanna do, so just making JIT not the default for the cases where it would use the pregenerated stuff is the present task? This means I guess figuring out the logic of |
On my Centos 8 VM
However with SELinux set to not enforcing, it's possible to set |
Now that I think about it, I wasn't building with SDL2 in Debian 9, just the packaged SDL 1.2, because this fork although it has SDL2 support it isn't quite right -- it seems to have a random chance of a deadlock on launch with SDL2 which resembles one that is fixed in other forks |
Well for now I'm going to say no rush on this PR. :) SheepShaver is a basket case and is going to need some time and debugging to fix. |
Fair enough. If you ever run out of expectations that it is something it's not, whatever it is it will still be here. |
Okay tried it again and it seems to work this time. CentOS 8 x86_64 with SELinux disabled and the mmap limit off, built with real addressing and with JIT enabled will boot to a desktop with a System 7.6.1 install CD:
JIT disabled seems to give me the same crash at "Welcome to Mac OS" I get with direct addressing. So I think we're at least on the same page now. :) |
#144 should fix that JIT disabled crash for both of those cases. |
Thanks very much for contributing this! Is there a test that can be added to demonstrate the fixed code as part of CI? Also, does this need a corresponding documentation change as you indicated in the issue? |
Not sure what's documented right now, but no don't tell people to disable security features. The idea is a default build should just work without having to do anything special. My ulterior motive here is I'd like to see Basilisk II return to the Debian repositories and turning off security features is going to be a no-go there. And it looks like SheepShaver has never even been in Debian. With BII/SS more widely available we might even attract more developers to fix things. :) |
The way forward is to fix SheepShaver JIT so it can run with direct addressing. rakslice are you working on that? :) |
My ulterior motive is to see the build system and CI improved a bit... the build system is "artisanal" and the CI is mostly just compile tests at the moment. So I think we are working toward the same goal. Should we open a separate issue to simply remove the "real addressing" code at a later point? What are the chances that it would be needed going forward? |
As this fork seems focused on current systems, once JIT works with direct addressing, real addressing could probably be entirely ripped out yes. Something for a future PR. :) |
Please open issues for those tasks. I'm not trying to be lazy, I just don't think I can properly articulate the interaction between the JIT and the rest. Besides that, @rakslice is this good to merge? |
For the purposes of this pull request I presume what we want is to just disable the SheepShaver JIT on the platforms where it won't work because the addressing mode has changed and it doesn't match the pregenerated stuff. Am I working on that? No, I assumed you were going to do that as a change in this PR since it's just a configure script change, but I'll take a look. Now, in the philosophical sense, I'm working on getting rid of the perpetual stumbling block of being stuck with a SheepShaver JIT with parts that can only be built with an ancient compiler, and if/when that gets done you would be able to just rebuild everything no matter the addressing mode or whatever other depended-on config options, but that's not based on this fork and needs a heck of a lot more testing, and probably rework in places to not be awful proof of concept experimental code. As far as the half-way point of just trying to figure out whatever the current pregenerated stuff was built with, so we can rebuild it with that with different options, well, I was hoping someone would answer the question cebix/macemu#222 before I had to go follow any more leads but I guess I can get back on that |
If there's anything I can add to CI to surface the testing efforts (to prevent regressions in the future) please let me know |
…h direct addressing.
Alright if SheepShaver JIT is definitely broken (with direct addressing) for now, disable it by default. |
Which platforms is it broken on? Or what does "platform" indicate in this case? |
When I tear real addressing out of SheepShaver, JIT will be broken on all platforms. :) |
Modern security standards mean real addressing is not possible on Linux/FreeBSD systems going forward. Instead of disabling security measures, simply use direct addressing instead.
If you are attached to real addressing for some reason, you are free to override the default build. :)
fixes #135