(idle_wait) until events arrived and notified through TriggerInterrupt().
i.e. we no longer sleep a fixed amount of time on platforms that support
a thread wait/signal mechanism.
i.e. it returned EPERM and ran into stack corruption to eventually crash the
emulator. This is noticeable in !hw_mac_cursor_accl mode (e.g. fullscreen DGA).
In order to the sigalstack() to be effective, we must kludge the kernel to
think it's running on another stack. In practise, we provide another stack
for the SIGUSR2 handler. sigusr2_handler_init() fulfills that purpose.
I hope this fixes remaining issues forever. At some point, I had multiple
*_init() handlers in case this is necessary.
for systems that use a global r2 as the TLS register, e.g. Linux/ppc with
newer glibc. Also remove the syscall junk which were simply workarounds
for this bug. Remove a duplicate r2 restoration in EmulOp.
BTW, it's possible to get SheepShaver running on Linux/ppc systems with
NPTL rather than SheepThreads.
to /dev/mem is required on Linux to use XF86 DGA mode. Otherwise, there is
now a fallback to fbdev.
- Forward port some features from Basilisk II (set_window_name,
disable_mouse_accel).
- Don't SIGSTOP the emulation thread on suspend since that would completely
stop the process on Linux. Use a frame buffer lock instead (as B2 does)
in that case. Tell me if I broke other arches, e.g. r13 is no longer saved
in Video and Ethernet stubs, though it seems to be OK.
Colateral feature: SheepShaver should now run on Linux/ppc64 with relevant
32-bit runtime. Native Linux/ppc64 support is harder as low mem globals are
32-bit in mind and e.g. the TLS register there is %r13, %r2 is the TOC
(PowerOpen/AIX ABI)
a read-only page, it can also be used to detect overlaps between Procedure
space and Data space.
Provide native Windows implementation of shared MacOS KernelData allocation.
This is moved under main() so that to avoid a weird linking error. This native
implementation is independent of Cygwin IPC (and possible background server)
code was also trying to access Serial memory.
Note however that I noticed some rare crashes with the DR emulator.
Probably caused by nested runs from EmulOps? We'd really want a native
68k emulator too for Execute68k() things.
This may be due to some switch mode that needs to save r13 and upwards.
The faultive code seems to explicitly add 0xee to r1, which causes it to
be unaligned for upcoming lmw/stmw.
