Compiler explorer -> https://gcc.godbolt.org/z/r8hj7W

This worked before GCC 7, was broken through GCC 7 and 8, and started working again in GCC 9, so I'm guessing it's a bug.

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

Output constraints: + constraint modifier -> "Means that this operand is both read and written by the instruction." d constraint, x86 family -> The d register

Input constraints: a constraint, x86 family -> The a register

Okay, none of that seems to be the problem. Technically the compiler should be told the assembly template modifies eax, but with no actual code afterward in the function to possibly be confused by that, it makes no difference.

It would seem that gcc knew to apply the constraint for %0, clearly %0 was %edx as far as the template application was concerned, and it emitted movl %ebx, %edx to put the input value in, but just neglected to take the result out.

I don't know if there is some obvious caveat about this case that I'm missing.

Looking at the code I was getting in Windows: (Intel-style disassemblies)

0:  49 63 c4                movsxd rax,r12d
3:  48 63 db                movsxd rbx,ebx
6:  48 0f af d8             imul   rbx,rax
a:  48 c1 eb 20             shr    rbx,0x20

From cygwin precompiled dyngen:

0:  89 da                   mov    edx,ebx
2:  89 f0                   mov    eax,esi
4:  f7 ea                   imul   edx
6:  89 d3                   mov    ebx,edx

(linux x86_64 debian gcc 8) Doing a powerpc-test of JIT against results from non-JIT run on the same builds, in both the real and direct addressing builds, mulhw and friends fail:

Testing mulhw
FAIL: mulhw [7c642896]
 00000000, 10000000, 00000000, 00000000 => 00000000 [__,__,__,__,__,__]
 00000000, 10000000, 00000000, 00000000 => 10000000 [__,__,__,__,__,__]
FAIL: mulhw [7c642896]
 00000000, 10000000, 00000000, 00000000 => 00000000 [__,__,__,__,__,__]
 00000000, 10000000, 00000000, 00000000 => 10000000 [__,__,__,__,__,__]

Looking at the JIT case for this, in ppc-translate.cpp:

		case PPC_I(MULHW):		// Multiply High Word
		case PPC_I(MULHWU):		// Multiply High Word Unsigned
		{
			dg.gen_load_T0_GPR(rA_field::extract(opcode));
			dg.gen_load_T1_GPR(rB_field::extract(opcode));
			if (ii->mnemo == PPC_I(MULHW))
				dg.gen_mulhw_T0_T1();
			else
				dg.gen_mulhwu_T0_T1();
			dg.gen_store_T0_GPR(rD_field::extract(opcode));
			if (Rc_field::test(opcode))
				dg.gen_record_cr0_T0();
			break;
		}

On this platform T0 is *bx, T1 is r12*.

The C++ code in ppc-dyngen-ops.cpp that compiles to the dyngen assembly block in gen_mulhw_T0_T1 is:

/**
 *		Multiply instructions
 **/

void OPPROTO op_mulhw_T0_T1(void)
{
#if DYNGEN_ASM_OPTS
#if defined(__i386__) || defined(__x86_64__)
	asm volatile ("imul %0" : "+d" (T0) : "a" (T1));
	return;
#endif
#endif
	T0 = (((int64)(int32)T0) * ((int64)(int32)T1)) >> 32;
}

Note in particular that MULHW should give the most significant bits:

Computes the most significant 32 bits of the 64-bit product of two 32-bit integers.

Hence the right shift in the C++ implementation.

Looking at the x86_64 assembly that is actually generated:

capstone disassembly for op_mulhw_T0_T1:
0x22d9:       movl %ebx, %edx                               89 da 
0x22db:       movl %r12d, %eax                              44 89 e0 
0x22de:      imull %edx                                     f7 ea 
0x22e0:       retq                                          c3 

I guess we're getting the DYNGEN_ASM_OPTS case?

Single operand imull reg is %eax * reg -> %edx:%eax, so basically this block is only doing %eax * %edx -> %edx:%eax, in other words it's leaving the part of the result we want in %edx and not actually putting it in T0 (%ebx).

(linux x86_64 debian gcc 8) I did a direct offset addressing build, since weird low host memory accesses will segfault right away and I have the flexibility to. That crashes rather than hanging:

Thread 1 "SheepShaver" received signal SIGSEGV, Segmentation fault.
0x0000000041ff3b61 in ?? ()
1: x/i $pc
=> 0x41ff3b61:  mov    0x10000000(%r12d,%eax,1),%eax

(gdb) disas /r $pc-40+3,+80
Dump of assembler code from 0x41ff3b3c to 0x41ff3b8c:
   0x0000000041ff3b3c:  89 9d 8c 00 00 00       mov    %ebx,0x8c(%rbp)
   0x0000000041ff3b42:  31 db   xor    %ebx,%ebx
   0x0000000041ff3b44:  89 5d 30        mov    %ebx,0x30(%rbp)
   0x0000000041ff3b47:  48 8d 05 b3 c4 00 be    lea    -0x41ff3b4d(%rip),%rax        # 0x1
   0x0000000041ff3b4e:  8d 18   lea    (%rax),%ebx
   0x0000000041ff3b50:  89 5d 28        mov    %ebx,0x28(%rbp)
   0x0000000041ff3b53:  44 8b a5 8c 00 00 00    mov    0x8c(%rbp),%r12d
   0x0000000041ff3b5a:  48 8d 05 a3 c4 00 be    lea    -0x41ff3b5d(%rip),%rax        # 0x4
=> 0x0000000041ff3b61:  67 41 8b 84 04 00 00 00 10      mov    0x10000000(%r12d,%eax,1),%eax
   0x0000000041ff3b6a:  0f c8   bswap  %eax
   0x0000000041ff3b6c:  89 c3   mov    %eax,%ebx
   0x0000000041ff3b6e:  89 5d 34        mov    %ebx,0x34(%rbp)
   0x0000000041ff3b71:  8b 5d 34        mov    0x34(%rbp),%ebx
   0x0000000041ff3b74:  48 8d 0d 87 c4 00 be    lea    -0x41ff3b79(%rip),%rcx        # 0x2
   0x0000000041ff3b7b:  48 8d 05 7f c4 00 be    lea    -0x41ff3b81(%rip),%rax        # 0x1
   0x0000000041ff3b82:  d3 c3   rol    %cl,%ebx
   0x0000000041ff3b84:  21 c3   and    %eax,%ebx
   0x0000000041ff3b86:  89 5d 1c        mov    %ebx,0x1c(%rbp)
   0x0000000041ff3b89:  8b 95 90 03 00 00       mov    0x390(%rbp),%edx
End of assembler dump.
(gdb) 

This has the feel of a problem with an outside factor like something persisting between runs, network behaviour differences, etc.

(linux x86_64 debian gcc 8) I don't really have a seam to take hold of...

• regular boot - boot progress stops indefinitely with cursor still responsive
• extensions off - hangs at the desktop

The crash repeats every boot if I retry a normal boot.

Booting extensions off works okay, and subsequent boots sometimes work normally with no change at all.

SIGSEGV
  pc 004687cc
  ea 10ffffff
 r0 009a82ac   r1 0bff4da8   r2 008dd248   r3 0000010f
 r4 00000000   r5 0bff5044   r6 00000005   r7 f400b21c
 r8 008dd37c   r9 00000010  r10 0bff4de4  r11 001de890
r12 008dd308  r13 008cb0a0  r14 000054b8  r15 0c000190
r16 008d2220  r17 008d2200  r18 02618000  r19 00003000
r20 008dd808  r21 00000016  r22 00000001  r23 008dd7d0
r24 008dd7a0  r25 00000000  r26 008dd818  r27 00000000
r28 00000000  r29 0bff5044  r30 00000005  r31 008dd37d
 f0 0.00000   f1 0.00000   f2 0.00000   f3 0.00000
 f4 4503599631312538.00000   f5 4503599631312430.00000   f6 4503599627370496.00000   f7 4503599627370496.00000
 f8 98548375.00000   f9 0.00000  f10 0.00000  f11 0.00000
f12 108000.00000  f13 8.00000  f14 0.00000  f15 0.00000
f16 0.00000  f17 0.00000  f18 0.00000  f19 0.00000
f20 0.00000  f21 0.00000  f22 0.00000  f23 0.00000
f24 0.00000  f25 0.00000  f26 0.00000  f27 0.00000
f28 0.00000  f29 0.00000  f30 0.00000  f31 0.00000
 lr 009a9018  ctr 001d9658   cr 24000448  xer 00000000
 pc 009a8fe4 fpscr 02008000
SheepShaver V2.5 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
Using SDL/wasapi audio output
Using SDL_Renderer driver: software
Detected CPU features: MMX SSE SSE2 SSE3 SSSE3
PowerPC CPU emulator by Gwenole Beauchesne
WARNING: Unknown DiskStatus(6)
  0x  9a8fc4:  lbz     r7,0(r3)
  0x  9a8fc8:  mr      r31,r4
  0x  9a8fcc:  addi    r3,r3,1
  0x  9a8fd0:  extsb.  r7,r7
  0x  9a8fd4:  li      r28,0
  0x  9a8fd8:  stb     r7,61(r1)
  0x  9a8fdc:  li      r9,1
  0x  9a8fe0:  beq-    0x9a900c
 >0x  9a8fe4:  addi    r7,r1,60
  0x  9a8fe8:  neg     r7,r7
  0x  9a8fec:  addi    r10,r1,60
  0x  9a8ff0:  addi    r8,r3,-1
  0x  9a8ff4:  add     r9,r9,r10
  0x  9a8ff8:  lbzu    r4,1(r8)
  0x  9a8ffc:  extsb.  r4,r4
  0x  9a9000:  stbu    r4,1(r9)
  0x  9a9004:  bne+    0x9a8ff8

Just specifying -ffixed-ebp stops that from happening fwiw, but I'm still uneasy about having to use a solution involving expecting the compiler flags to work

(x86 32-bit Windows) Carrying with x86 32-bit Windows, which is what I originally started looking at, I've been trying to get a working set of gcc parameters for the *-dyngen-ops.o builds that are the input files of the dyngen.

I'm currently at: -fomit-frame-pointer -falign-functions=0 -finline-limit=10000 -fno-reorder-blocks -fno-optimize-sibling-calls -fno-reorder-functions -fno-reorder-blocks-and-partition

Of note here:

• -falign-functions - avoid unexpected ordering of functions; this is helpful for functions op_branch_*'s that we don't do our basic block analysis on because they contain an external jump it doesn't know what to make of, so we mostly need the original compiled version to be in the right order already at the moment
• -fno-optimize-sibling-calls - avoid jumps that are too long for our current 2-byte relative jumps
• -fno-reorder-functions - avoid extra .text.unlikely blocks
• -fno-reorder-blocks-and-partition - disable optimization that partitions functions into cold and hot cache lines to avoid e.g. extra .cold symbols
• leaving out -mpreferred-stack-boundary=2 avoids the infamous frame pointer required, but reserved

However currently this is producing routines in ppc-dyngen-ops.o that use %ebp without preserving it despite it being callee-saved if I'm not totally misunderstanding the situation; maybe this is some kind of leaf function optimization?

00002862 <__Z12op_lmw_T0_imv>:
    2862:       b9 00 00 00 00          mov    $0x0,%ecx
    2867:       83 f9 1f                cmp    $0x1f,%ecx
    286a:       77 2e                   ja     289a <__Z12op_lmw_T0_imv+0x38>
    286c:       bd 20 00 40 04          mov    $0x4400020,%ebp
    2871:       8d 93 00 00 00 11       lea    0x11000000(%ebx),%edx
    2877:       29 cd                   sub    %ecx,%ebp
    2879:       8d 2c ab                lea    (%ebx,%ebp,4),%ebp
    287c:       8d 4c 8d 00             lea    0x0(%ebp,%ecx,4),%ecx
    2880:       29 d9                   sub    %ebx,%ecx
    2882:       8d b6 00 00 00 00       lea    0x0(%esi),%esi
    2888:       8b 02                   mov    (%edx),%eax
    288a:       0f c8                   bswap  %eax
    288c:       89 84 11 10 00 00 ef    mov    %eax,-0x10fffff0(%ecx,%edx,1)
    2893:       83 c2 04                add    $0x4,%edx
    2896:       39 ea                   cmp    %ebp,%edx
    2898:       75 ee                   jne    2888 <__Z12op_lmw_T0_imv+0x26>
    289a:       c3                      ret

0000289b <__Z13op_stmw_T0_imv>:
    289b:       b9 00 00 00 00          mov    $0x0,%ecx
    28a0:       83 f9 1f                cmp    $0x1f,%ecx
    28a3:       77 2d                   ja     28d2 <__Z13op_stmw_T0_imv+0x37>
    28a5:       bd 20 00 40 04          mov    $0x4400020,%ebp
    28aa:       8d 93 00 00 00 11       lea    0x11000000(%ebx),%edx
    28b0:       29 cd                   sub    %ecx,%ebp
    28b2:       8d 2c ab                lea    (%ebx,%ebp,4),%ebp
    28b5:       8d 4c 8d 00             lea    0x0(%ebp,%ecx,4),%ecx
    28b9:       29 d9                   sub    %ebx,%ecx
    28bb:       8d 74 26 00             lea    0x0(%esi,%eiz,1),%esi
    28bf:       90                      nop
    28c0:       8b 84 11 10 00 00 ef    mov    -0x10fffff0(%ecx,%edx,1),%eax
    28c7:       0f c8                   bswap  %eax
    28c9:       89 02                   mov    %eax,(%edx)
    28cb:       83 c2 04                add    $0x4,%edx
    28ce:       39 ea                   cmp    %ebp,%edx
    28d0:       75 ee                   jne    28c0 <__Z13op_stmw_T0_imv+0x25>
    28d2:       c3                      ret

In B2, a frequent slirp segfault is

#0  0x0053738e in soread (so=so@entry=0x831ef38) at ../slirp/socket.c:104
#1  0x00534f9c in slirp_select_poll (readfds=readfds@entry=0x881fc0c, writefds=writefds@entry=0x881fd10, xfds=xfds@entry=0x881fe14) at ../slirp/slirp.c:412
#2  0x00410284 in slirp_receive_func (arg=0x0) at ether_windows.cpp:1392

here initializing at the top of soread:

104             int mss = so->so_tcpcb->t_maxseg;

with so->so_tcpcb 0 or 0xfeeefeee (MS C runtime placeholder value indicating the heap at the location has already been freed, so in this instance presumably the struct socket pointed to by so has already been freed.)

I don't have an exact procedure to cause this segfault 100% of the time, but doing a process of launching B2, running Netscape 2 in Mac OS 7.6.1, with its stock Open Transport 1.1.1, and visiting and browsing around a couple of sites, which includes

• a local python SimpleHTTPServer that I use to serve my classic mac files
• system7today.com

and then shutting down, I usually reproduce the problem in two or three boots.

[Update: A more reliable way to hit the bug is something that definitely closes a TCP connection locally on the emulated Mac, such as closing a telnet connection in NCSA Telnet]

slirp issue was just having disabled the winsock errno macro mappings. whoops.

Fixes rakslice/macemu#39

In Windows, closing a telnet session in NCSA Telnet from the client side is a more likely way of hitting the bug :D

Linux: Ah, this is just down to normal browser behaviour, I guess; a quick test of closing a session from the local side in NCSA Telnet does call slirp_input as expected.

Okay, so in ether_unix, the emulated machine is connected to slirp with pipes for some reason. The emulated machine's call to send a packet just puts it into the pipe.

slirp_input(), which is called for the packets inbound to slirp from the emulated machine, in ether_unix is actually done inside the slirp_receive_func thread. It alternates between selects for slirp's sockets and a select on the inbound packets pipe, which has its own set of possible consequences, but at least guarantees that only one slirp function call can be in progress at once.

That means that this bug doesn't apply to Unix.

But the question of why in practice no sockets close due to tcp_input is still unanswered.

Testing in Linux, weirdly all the tcp_close calls come from tcp_slowtimo...

Avoiding all the temporary copies of source files when working on the Windows version is a real nuisance.

See about augmenting the build process to use the common code in place.

But if slirp already doesn't have a kind of critical section it uses, this is a big hint that it's not designed to have its functions called concurrently on multiple threads.

I imagine that there is some way to a fix this specific problem where we

• reorder tcp_close so that the socket being closed is properly taken out of active processing before invalidating it in such a way that causes undefined behaviour in other functions trying to use it
• provide some kind of safeguard against tcp_close of a socket happening while the select poll tcp for loop is visiting that socket
• deal with the for loop's so_next potentially becoming invalid because of a simultaneous close

When I run into this one with so->so_tcpcb equal 0, what the ether_thread_write_packets thread is doing at the time is that as suggested by the multiple threads it's in tcp_close, past the so->so_tcpcb = 0 line and not yet to sofree(so):

104             int mss = so->so_tcpcb->t_maxseg;
(gdb) bt
#0  0x0053738e in soread (so=so@entry=0xcdc5e40) at ../slirp/socket.c:104
#1  0x00534f9c in slirp_select_poll (readfds=readfds@entry=0x883fc0c,
    writefds=writefds@entry=0x883fd10, xfds=xfds@entry=0x883fe14)
    at ../slirp/slirp.c:412
#2  0x00410284 in slirp_receive_func (arg=0x0)
    at C:/msys32/home/Andrew Tonner/src/macemu/BasiliskII/src/Windows/ether_windows.cpp:1420
#3  0x76726cff in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll
#4  0x76726dc1 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll
#5  0x764ffa29 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#6  0x772975f4 in ntdll!RtlGetAppContainerNamedObjectPath ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#7  0x772975c4 in ntdll!RtlGetAppContainerNamedObjectPath ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0x00000000 in ?? ()
(gdb) thread 9
[Switching to thread 9 (Thread 28060.0x6574)]
#0  0x77278b7a in ntdll!RtlGetCurrentServiceSessionId ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x77278b7a in ntdll!RtlGetCurrentServiceSessionId ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x257ecf32 in ?? ()
#2  0x0cdc5f80 in ?? ()
#3  0x772b621d in ntdll!RtlGetNtGlobalFlags ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x0cdc5f80 in ?? ()
#5  0x77278786 in ntdll!RtlFreeHeap () from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x7730f687 in ntdll!RtlRegisterSecureMemoryCacheCallback ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#7  0x772c67e0 in ntdll!RtlCaptureStackContext ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0x772b621d in ntdll!RtlGetNtGlobalFlags ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#9  0x0cdc5f80 in ?? ()
#10 0x77278786 in ntdll!RtlFreeHeap () from C:\WINDOWS\SYSTEM32\ntdll.dll
#11 0x76707379 in msvcrt!free () from C:\WINDOWS\System32\msvcrt.dll
#12 0x02090000 in ?? ()
#13 0x005318b0 in tcp_close (tp=tp@entry=0xcdc5ec0) at ../slirp/tcp_subr.c:303
#14 0x0052e54d in tcp_input (m=m@entry=0xcdbcd00, iphlen=<optimized out>,
    iphlen@entry=20, inso=inso@entry=0x0) at ../slirp/tcp_input.c:977
#15 0x00535f8b in ip_input (m=0xcdbcd00) at ../slirp/ip_input.c:222
#16 0x00535226 in slirp_input (pkt=<optimized out>, pkt_len=72)
    at ../slirp/slirp.c:628
#17 0x004108d2 in ether_thread_write_packets (arg=0x0)
    at C:/msys32/home/Andrew Tonner/src/macemu/BasiliskII/src/Windows/ether_windows.cpp:1037
#18 0x76726cff in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll
#19 0x76726dc1 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll
#20 0x764ffa29 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#21 0x772975f4 in ntdll!RtlGetAppContainerNamedObjectPath ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#22 0x772975c4 in ntdll!RtlGetAppContainerNamedObjectPath ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#23 0x00000000 in ?? ()
(gdb) f 13
#13 0x005318b0 in tcp_close (tp=tp@entry=0xcdc5ec0) at ../slirp/tcp_subr.c:303
303             sbfree(&so->so_snd);
(gdb) list
298             /* clobber input socket cache if we're closing the cached connection */
299             if (so == tcp_last_so)
300                     tcp_last_so = &tcb;
301             closesocket(so->s);
302             sbfree(&so->so_rcv);
303             sbfree(&so->so_snd);
304             sofree(so);
305             tcpstat.tcps_closed++;
306             return ((struct tcpcb *)0);
307     }

When moving the cursor down pull-down menus I notice some glitchyness of the selection drawing, where it appears in multiple separate horizontal blocks, suggestive of screen tearing.

I know in the internals somewhere there is some kind of frame interval. I don't know if that's hooked up to anything.

Look into what vsync we can get basically for free on the output side from SDL2, and look into hooking it up to the mac side.

For the case where so->so_tcpcb is 0, it is being set to 0 during tcp_close.

There are ways into tcp_close:

From within slirp_select_poll cleaning up sockets:

#0  tcp_close (tp=0x81ea840) at ../slirp/tcp_subr.c:282
#1  0x00533e04 in tcp_slowtimo () at ../slirp/tcp_timer.c:94
#2  0x00535152 in slirp_select_poll (readfds=readfds@entry=0x883fc0c,
    writefds=writefds@entry=0x883fd10, xfds=xfds@entry=0x883fe14)
    at ../slirp/slirp.c:374
#3  0x00410284 in slirp_receive_func (arg=0x0) at ether_windows.cpp:1392
#4  0x76726cff in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll
#5  0x76726dc1 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll
#6  0x764ffa29 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#7  0x772975f4 in ntdll!RtlGetAppContainerNamedObjectPath ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0x772975c4 in ntdll!RtlGetAppContainerNamedObjectPath ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#9  0x00000000 in ?? ()

From input. This comes from a different thread (!)

(gdb) bt
#0  tcp_close (tp=tp@entry=0x81ccf00) at ../slirp/tcp_subr.c:294
#1  0x0052e57d in tcp_input (m=m@entry=0x81ca0a8, iphlen=<optimized out>,
    iphlen@entry=20, inso=inso@entry=0x0) at ../slirp/tcp_input.c:978
#2  0x0053610b in ip_input (m=0x81ca0a8) at ../slirp/ip_input.c:222
#3  0x005353a6 in slirp_input (pkt=<optimized out>, pkt_len=72)
    at ../slirp/slirp.c:637
#4  0x004108d2 in ether_thread_write_packets (arg=0x0)
    at ether_windows.cpp:1021
#5  0x76726cff in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll
#6  0x76726dc1 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll
#7  0x764ffa29 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#8  0x772975f4 in ntdll!RtlGetAppContainerNamedObjectPath ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#9  0x772975c4 in ntdll!RtlGetAppContainerNamedObjectPath ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#10 0x00000000 in ?? ()

At this point in slirp_select_poll, looking at the "Check TCP sockets" for loop we are inside, at the top of the loop the first thing it does is cache the so 1 ahead after the current one into so_next. Since I just wrote code precisely like this in the loop that rearranges the drive queue, ;) I'm going to presume that this is a cheap trick to get around the fact that the code within the loop in some case needs to take the current node out of the list and wants to not lose its place. However if, In the course of doing this, there is a possibility of the next node also being modified (in such a way that becomes freed or otherwise so_tcpcb-invalid), and it is taken out of the list to avoid a problem, then that cached so 1 ahead is actually a liability.

In B2, a frequent slirp segfault is

#0  0x0053738e in soread (so=so@entry=0x831ef38) at ../slirp/socket.c:104
#1  0x00534f9c in slirp_select_poll (readfds=readfds@entry=0x881fc0c, writefds=writefds@entry=0x881fd10, xfds=xfds@entry=0x881fe14) at ../slirp/slirp.c:412
#2  0x00410284 in slirp_receive_func (arg=0x0) at ether_windows.cpp:1392

here initializing at the top of soread:

104             int mss = so->so_tcpcb->t_maxseg;

with so->so_tcpcb 0 or 0xfeeefeee (MS C runtime placeholder value indicating the heap at this location, so presumably the struct socket pointed to by so, has already been freed.

I'd be much obliged if you can take 5 minutes to look at emaculation/shoebill#1 and see if that windows build is misconfigured in some obvious way

I mean, why is it configured to do what it's doing now? I don't know much about cygwin 64, or shoebill, but presumably if it's missing a header you make sure the package it would be in is in the list of packages you're installing?

up to the crashing execute:

gen_op_store_T0_GPR27 at 77060f6
gen_op_add_32_T1_2 at 77060fa
gen_op_store_T1_GPR24 at 77060fe
gen_op_load_T0_crb31 at 7706102
gen_op_load_T1_crb31 at 770610c
gen_op_nor_32_T0_T1 at 7706117
gen_op_store_T0_crb2 at 770611c
gen_op_load_T0_LR_aligned at 770613c
gen_op_load_T1_crb8 at 7706146
gen_op_prep_branch_bo_001x at 7706155
gen_op_branch_2_T0_im at 7706160
gen_op_mov_ad_A0_im at 770617d
gen_op_jump_next_A0 at 7706187
gen_op_jmp_fast at 77061b9
gen_op_spcflags_check at 77061c0
gen_op_set_PC_im at 77061cf (0x40c90c08)
gen_op_jmp_fast at 77061e7
gen_op_load_T0_GPR9 at 77061f0
gen_op_load_T1_GPR0 at 77061f4
gen_op_addco_T0_T1 at 77061f8
gen_op_record_cr0_T0 at 7706236
gen_op_store_T0_GPR4 at 770627f
gen_op_load_T0_GPR27 at 7706283
gen_op_se_8_32_T0 at 7706287
gen_op_store_T0_GPR7 at 770628a
gen_op_load_T0_GPR30 at 770628e
gen_op_or_32_T0_im at 7706295
gen_op_store_T0_GPR5 at 77062a5
gen_op_load_T0_GPR7 at 77062a9
gen_op_load_T1_GPR16 at 77062ad
gen_op_add_32_T0_T1 at 77062b1
gen_op_store_T0_GPR3 at 77062b4
gen_op_load_T0_GPR5 at 77062b8
gen_op_store_T0_LR at 77062bc
gen_op_load_T0_GPR27 at 77062c3
gen_op_rlwinm_T0_T1 at 77062c7
gen_op_store_T0_GPR5 at 77062e8
gen_op_load_T0_GPR5 at 77062ec
gen_op_load_T1_GPR30 at 77062f0
gen_op_add_32_T0_T1 at 77062f7
gen_op_store_T0_GPR5 at 77062fa
gen_op_load_T0_GPR5 at 77062fe
gen_op_store_T0_CTR at 7706302
gen_op_load_T1_GPR24 at 7706309
gen_op_load_s16_T0_T1_im at 770630d
gen_op_store_T0_GPR27 at 770632f
gen_op_add_32_T1_2 at 7706333
gen_op_store_T1_GPR24 at 7706337
gen_op_load_T0_CTR_aligned at 770633b
gen_op_prep_branch_bo_1x1x at 7706345
gen_op_branch_1_T0 at 770634b
gen_op_mov_ad_A0_im at 7706352
gen_op_jump_next_A0 at 770635c
gen_op_jmp_fast at 770638e
in execute 00000000077061c0

printing the value of this in powerpc_cpu::execute() also makes the crash go away

okay, a printf of the entry point within execute() doesn't crash; the value suggests the last thing executeed was an op_spcflags_check

(Windows x86_64) While trying to come up some clues about the location of the crash with all objs optimized, I put a printf showing bi->entry_point in powerpc_cpu::execute(), and that makes the crash go away.

I don't know why.

Having the printf causes entry_point and even bi to not be optimized out when they otherwise are; I don't know how to otherwise force that to check it in isolation.

And I really don't know why that would make any difference.

So where are we at? (Windows x86_64)

• builds with some files unoptimized running ok
• need to investigate the crashes when ppc-cpu.cpp and ppc-dyngen.cpp are optimized
• any other issues? (Linux x86_64)
• some distros needing -fomit-frame-pointer, others don't, need to figure out, if not why, at least what to do about it
• issues at runtime, there are still segfaults under debugger that we could pull on. relatively far in to the boot
• some at repeatable ppc locations, maybe need to investigate what the parameters to that basic block are for jit vs no jit

I gave Cockatrice III a heads up because this goes back to BII 0.8 code, but testing their build it doesn't seem to have any effect like this playback crash there.

https://sourceforge.net/p/cockatrice/tickets/2/

The first playback of audio in an application after startup works fine, but when I exit and launch the application again, audio playback causes various kinds of fatal error.

I can stop and start and close and reopen the same or different files in the application an unlimited number of times, it's just the playback after the first application launched that played audio has exited that has the problem.

• The application doesn't seem to matter; I noticed it when using Audion, mpegdec, but Quicktime Player is affected (even QuickTime MoviePlayer 2.5 in System 7.x)
• Both BII and SS
• Mac OS any I've tried
• JIT or no JIT
• Both newworld and oldworld ROM in SS
• I'm testing version 02c037b5cb99944ef627c798b4aa9b933b24b05f
• I'm testing in Windows

SS: The error takes a variety of forms at random:

• unhandled segfault of SS
• Type 3 error
• Type 8xxx error
• "Sorry, a system error occurred."
• A few percent of the time there is no error; if there is no error, I can generally restart the same application many times in the OS session and playback still won't error.

BII:

• unimplemented trap
• CHK error
• A good fraction of the time there is no error

Investigating SS unhandled segfault further in gdb, I find that it's in various delegated calls in audio.cpp, not always the same one, but in or soon after the InitOutputDevice of the second audio session.

With DEBUG set in audio.cpp:

Start and first audio session:

warning: B2: 10/20/20 15:07:32:229 SoundInOpen
warning: B2: 10/20/20 15:07:32:234 SoundInStatus 2
[New Thread 10724.0x6464]
warning: B2: 10/20/20 15:08:09:191 AudioDispatch params 0bff583e (size 4), what -1
warning: B2: 10/20/20 15:08:09:198  global data at 000ff770
warning: B2: 10/20/20 15:08:09:205 AudioDispatch params 0bff5890 (size 0), what -5
warning: B2: 10/20/20 15:08:09:210 AudioDispatch params 0bff585e (size 4), what -2
warning: B2: 10/20/20 15:08:16:761 AudioDispatch params 0f6abc46 (size 4), what -1
warning: B2: 10/20/20 15:08:16:768  global data at 00c77f70
warning: B2: 10/20/20 15:08:16:772 AudioDispatch params 0f6abcc8 (size 12), what 259
warning: B2: 10/20/20 15:08:16:780  AudioGetInfo hvol, infoPtr 0f6abe18, source ID 00000
000
warning: B2: 10/20/20 15:08:16:786 AudioDispatch params 0f6abc88 (size 4), what -2
warning: B2: 10/20/20 15:08:30:074 AudioDispatch params 0dbef4e6 (size 4), what -1
warning: B2: 10/20/20 15:08:30:081  global data at 0d820c10
warning: B2: 10/20/20 15:08:30:085 AudioDispatch params 0dbef534 (size 4), what 1
warning: B2: 10/20/20 15:08:30:093  InitOutputDevice
warning: B2: 10/20/20 15:08:30:119  OpenMixer() returns 00000000, mixer 00920003
warning: B2: 10/20/20 15:08:30:128 AudioDispatch params 0dbef570 (size 4), what 257
warning: B2: 10/20/20 15:08:30:135  AddSource
warning: B2: 10/20/20 15:08:30:142  delegating call to Apple Mixer
warning: B2: 10/20/20 15:08:30:170  returns 00000000
warning: B2: 10/20/20 15:08:30:377 AudioDispatch params 0dbef08e (size 12), what 260
warning: B2: 10/20/20 15:08:30:384  AudioSetInfo volu, infoPtr 001f001f, source ID 00e29
810
warning: B2: 10/20/20 15:08:30:392   delegated to Apple Mixer, returns 00000000
warning: B2: 10/20/20 15:08:30:541 AudioDispatch params 0d7ff364 (size 6), what 262
warning: B2: 10/20/20 15:08:30:549  StopSource
warning: B2: 10/20/20 15:08:30:553  delegating call to Apple Mixer
warning: B2: 10/20/20 15:08:30:560  returns 00000000
warning: B2: 10/20/20 15:08:30:565 AudioDispatch params 0d7ff310 (size 12), what 259
warning: B2: 10/20/20 15:08:30:572  AudioGetInfo cmfa, infoPtr 00da6a2c, source ID 00e29
810
warning: B2: 10/20/20 15:08:30:581   delegated to Apple Mixer, returns ffffff19
warning: B2: 10/20/20 15:08:30:593 AudioDispatch params 0d7ff362 (size 12), what 264
warning: B2: 10/20/20 15:08:30:600  PlaySourceBuffer flags 00000001
warning: B2: 10/20/20 15:08:30:611  returns 00000000
warning: B2: 10/20/20 15:08:30:619 AudioDispatch params 0d7ff2f6 (size 12), what 259
warning: B2: 10/20/20 15:08:30:628  AudioGetInfo cmfa, infoPtr 00da6a2c, source ID 00e29
810

...

warning: B2: 10/20/20 15:08:33:625 AudioDispatch params 0f71dd5c (size 12), what 259
warning: B2: 10/20/20 15:08:33:632  AudioGetInfo cmfa, infoPtr 00da6a2c, source ID 00e29
810
warning: B2: 10/20/20 15:08:33:639   delegated to Apple Mixer, returns ffffff19
warning: B2: 10/20/20 15:08:33:683 AudioDispatch params 0dbf3994 (size 6), what 262
warning: B2: 10/20/20 15:08:33:692  StopSource
warning: B2: 10/20/20 15:08:33:695  delegating call to Apple Mixer
warning: B2: 10/20/20 15:08:33:702  returns 00000000
warning: B2: 10/20/20 15:08:33:710 AudioDispatch params 0dbf39a6 (size 6), what 262
warning: B2: 10/20/20 15:08:33:717  StopSource
warning: B2: 10/20/20 15:08:33:720  delegating call to Apple Mixer
warning: B2: 10/20/20 15:08:33:727  returns 00000000
warning: B2: 10/20/20 15:08:33:731 AudioDispatch params 0dbf3a04 (size 4), what 258
warning: B2: 10/20/20 15:08:33:737  RemoveSource
warning: B2: 10/20/20 15:08:33:743  delegating call to Apple Mixer
warning: B2: 10/20/20 15:08:33:750  returns 00000000
warning: B2: 10/20/20 15:08:33:756 AudioDispatch params 0dbf39b8 (size 4), what -2

Then, starting the second session (note the invalid zero mixer value from OpenMixer(), though the crash is sometimes before that so it may be a knock-on effect:

warning: B2: 10/20/20 15:11:11:461 AudioDispatch params 0dbff4e6 (size 4), what -1
warning: B2: 10/20/20 15:11:11:468 AudioDispatch params 0dbff534 (size 4), what 1
warning: B2: 10/20/20 15:11:11:475  InitOutputDevice
warning: B2: 10/20/20 15:11:11:479  OpenMixer() returns 00000000, mixer 00000000
warning: B2: 10/20/20 15:11:11:486 AudioDispatch params 0dbff570 (size 4), what 257
warning: B2: 10/20/20 15:11:11:494  AddSource
warning: B2: 10/20/20 15:11:11:497  delegating call to Apple Mixer
warning: B2: 10/20/20 15:11:11:501  returns 00000000
warning: B2: 10/20/20 15:11:11:634 AudioDispatch params 0dbff08e (size 12), what 260
warning: B2: 10/20/20 15:11:11:641  AudioSetInfo volu, infoPtr 001f001f, source ID 00000
000
warning: B2: 10/20/20 15:11:11:775 AudioDispatch params 0d80f374 (size 6), what 262
warning: B2: 10/20/20 15:11:11:782  StopSource
warning: B2: 10/20/20 15:11:11:785  delegating call to Apple Mixer

Thread 1 hit Catchpoint 2 (signal SIGSEGV), 0x0000000007642a4b in ?? ()
1: x/i $pc
=> 0x7642a4b:   movzwl 0x11000000(%r12d,%eax,1),%ebx
2: /x $rsp = 0x115f318
x86 pc 7642a4b mac pc 40c9db18
Pattern not found.
(gdb) p /x $r12d+$eax+1
$1 = 0xffffffff

This is a bug from prehistory https://github.com/rakslice/macemu/blame/3e58028cb14cdcbd2d2798055c1e863ed663e693/BasiliskII/src/audio.cpp#L402

Due to an errant early return, the deinitialization does not complete properly in the case where there was a mixer to close

Fixes rakslice/macemu#38

(Linux x86_64) I did some more changes to get building under Debian 10 (gcc 8.3.0). But not running - hangs or repeatable crashes depending on what I build and run.

elementary OS 5.1 Hera (Ubuntu 18.04 LTS bionic)'s gcc 7.5.0 is one of the things that emits internal calls within the blocks, making the end rets dual purpose, something that isn't handled yet.

The rdata issue was that the wrong offset was being used; there was already code to read the value out of the relocation offset and use it as the addend, I didn't need to further increment it by the addend (i.e. itself).

A cursory look at the forums finds a lot of stuff that could be down to this.

In the thread at https://www.emaculation.com/forum/viewtopic.php?t=5286 someone suggests turning on 'platinum' sound effects in Mac OS 9; this generates a lot of little random sound effects on Finder UI actions, which have the side effect of keeping the system away from whatever precondition is the problem

Also happens on Linux

Sound issue is not new and not SS specific; spun off to #38

This is not a new error; in older posted BII Windows builds the error was a "Type 10 Error" rather than "unimplemented trap"

While testing in BII in Mac OS 7.6.1 with a WAV file I can playback conveniently in the stock MoviePlayer 2.5, I found:

• In a Mac OS session where there is no other audio before MoviePlayer WAV, the second MoviePlayer WAV playback will have "unimplemented trap"
• After a system sound from the "This computer may not have been shut down properly" dialog or from dragging the slider in the Sound control panel, the second and repeated MoviePlayer WAV playback will work
• After a system sound from MoviePlayer's "Could not open .. because the file is not a movie file." dialog, the second MoviePlayer WAV playback will have "CHK error".
• After a system sound from MoviePlayer's "Could not open .. because the file is not a movie file." dialog, and the first MoviePlayer WAV playback, I then drag the slider in the sound control panel, the next and repeated MoviePlayer WAV playback after that will work.

This is consistent with sound being left in a good or bad state based on the previous app or the boot state (when there is no previous app), but not affecting not the next playback, only the one after that.

The first playback of audio in an application after startup works fine, but when I exit and launch the application again, audio playback causes various kinds of fatal error.

• The application doesn't seem to matter; I noticed it when using Audion, mpegdec, but Quicktime Player is affected (even stock 2.5 in System 7.x)
• Both BII and SS
• Mac OS any I've tried, both BII & SS
• Both newworld and oldworld ROM in SS
• I'm testing version 02c037b5cb99944ef627c798b4aa9b933b24b05f
• I'm testing in Windows

SS: The error takes a variety of forms at random:

• unhandled segfault of SS
• Type 3 error
• Type 8xxx error
• "Sorry, a system error occurred."
• A few percent of the time there is no error; if there is no error, I can generally restart the same application an many times in the session and playback still won't error.

BII:

• unimplemented trap
• CHK error
• A good fraction of the time there is no error

Investigating SS unhandled segfault further in gdb, I find that it's in various delegated calls in audio.cpp, not always the same one, but in or soon after the InitOutputDevice of the second audio session.

With DEBUG set in audio.cpp:

Start and first audio session:

warning: B2: 10/20/20 15:07:32:229 SoundInOpen
warning: B2: 10/20/20 15:07:32:234 SoundInStatus 2
[New Thread 10724.0x6464]
warning: B2: 10/20/20 15:08:09:191 AudioDispatch params 0bff583e (size 4), what -1
warning: B2: 10/20/20 15:08:09:198  global data at 000ff770
warning: B2: 10/20/20 15:08:09:205 AudioDispatch params 0bff5890 (size 0), what -5
warning: B2: 10/20/20 15:08:09:210 AudioDispatch params 0bff585e (size 4), what -2
warning: B2: 10/20/20 15:08:16:761 AudioDispatch params 0f6abc46 (size 4), what -1
warning: B2: 10/20/20 15:08:16:768  global data at 00c77f70
warning: B2: 10/20/20 15:08:16:772 AudioDispatch params 0f6abcc8 (size 12), what 259
warning: B2: 10/20/20 15:08:16:780  AudioGetInfo hvol, infoPtr 0f6abe18, source ID 00000
000
warning: B2: 10/20/20 15:08:16:786 AudioDispatch params 0f6abc88 (size 4), what -2
warning: B2: 10/20/20 15:08:30:074 AudioDispatch params 0dbef4e6 (size 4), what -1
warning: B2: 10/20/20 15:08:30:081  global data at 0d820c10
warning: B2: 10/20/20 15:08:30:085 AudioDispatch params 0dbef534 (size 4), what 1
warning: B2: 10/20/20 15:08:30:093  InitOutputDevice
warning: B2: 10/20/20 15:08:30:119  OpenMixer() returns 00000000, mixer 00920003
warning: B2: 10/20/20 15:08:30:128 AudioDispatch params 0dbef570 (size 4), what 257
warning: B2: 10/20/20 15:08:30:135  AddSource
warning: B2: 10/20/20 15:08:30:142  delegating call to Apple Mixer
warning: B2: 10/20/20 15:08:30:170  returns 00000000
warning: B2: 10/20/20 15:08:30:377 AudioDispatch params 0dbef08e (size 12), what 260
warning: B2: 10/20/20 15:08:30:384  AudioSetInfo volu, infoPtr 001f001f, source ID 00e29
810
warning: B2: 10/20/20 15:08:30:392   delegated to Apple Mixer, returns 00000000
warning: B2: 10/20/20 15:08:30:541 AudioDispatch params 0d7ff364 (size 6), what 262
warning: B2: 10/20/20 15:08:30:549  StopSource
warning: B2: 10/20/20 15:08:30:553  delegating call to Apple Mixer
warning: B2: 10/20/20 15:08:30:560  returns 00000000
warning: B2: 10/20/20 15:08:30:565 AudioDispatch params 0d7ff310 (size 12), what 259
warning: B2: 10/20/20 15:08:30:572  AudioGetInfo cmfa, infoPtr 00da6a2c, source ID 00e29
810
warning: B2: 10/20/20 15:08:30:581   delegated to Apple Mixer, returns ffffff19
warning: B2: 10/20/20 15:08:30:593 AudioDispatch params 0d7ff362 (size 12), what 264
warning: B2: 10/20/20 15:08:30:600  PlaySourceBuffer flags 00000001
warning: B2: 10/20/20 15:08:30:611  returns 00000000
warning: B2: 10/20/20 15:08:30:619 AudioDispatch params 0d7ff2f6 (size 12), what 259
warning: B2: 10/20/20 15:08:30:628  AudioGetInfo cmfa, infoPtr 00da6a2c, source ID 00e29
810

...

warning: B2: 10/20/20 15:08:33:625 AudioDispatch params 0f71dd5c (size 12), what 259
warning: B2: 10/20/20 15:08:33:632  AudioGetInfo cmfa, infoPtr 00da6a2c, source ID 00e29
810
warning: B2: 10/20/20 15:08:33:639   delegated to Apple Mixer, returns ffffff19
warning: B2: 10/20/20 15:08:33:683 AudioDispatch params 0dbf3994 (size 6), what 262
warning: B2: 10/20/20 15:08:33:692  StopSource
warning: B2: 10/20/20 15:08:33:695  delegating call to Apple Mixer
warning: B2: 10/20/20 15:08:33:702  returns 00000000
warning: B2: 10/20/20 15:08:33:710 AudioDispatch params 0dbf39a6 (size 6), what 262
warning: B2: 10/20/20 15:08:33:717  StopSource
warning: B2: 10/20/20 15:08:33:720  delegating call to Apple Mixer
warning: B2: 10/20/20 15:08:33:727  returns 00000000
warning: B2: 10/20/20 15:08:33:731 AudioDispatch params 0dbf3a04 (size 4), what 258
warning: B2: 10/20/20 15:08:33:737  RemoveSource
warning: B2: 10/20/20 15:08:33:743  delegating call to Apple Mixer
warning: B2: 10/20/20 15:08:33:750  returns 00000000
warning: B2: 10/20/20 15:08:33:756 AudioDispatch params 0dbf39b8 (size 4), what -2

Then, starting the second session (note the invalid zero mixer value from OpenMixer(), though the crash is sometimes before that so it may be a knock-on effect:

warning: B2: 10/20/20 15:11:11:461 AudioDispatch params 0dbff4e6 (size 4), what -1
warning: B2: 10/20/20 15:11:11:468 AudioDispatch params 0dbff534 (size 4), what 1
warning: B2: 10/20/20 15:11:11:475  InitOutputDevice
warning: B2: 10/20/20 15:11:11:479  OpenMixer() returns 00000000, mixer 00000000
warning: B2: 10/20/20 15:11:11:486 AudioDispatch params 0dbff570 (size 4), what 257
warning: B2: 10/20/20 15:11:11:494  AddSource
warning: B2: 10/20/20 15:11:11:497  delegating call to Apple Mixer
warning: B2: 10/20/20 15:11:11:501  returns 00000000
warning: B2: 10/20/20 15:11:11:634 AudioDispatch params 0dbff08e (size 12), what 260
warning: B2: 10/20/20 15:11:11:641  AudioSetInfo volu, infoPtr 001f001f, source ID 00000
000
warning: B2: 10/20/20 15:11:11:775 AudioDispatch params 0d80f374 (size 6), what 262
warning: B2: 10/20/20 15:11:11:782  StopSource
warning: B2: 10/20/20 15:11:11:785  delegating call to Apple Mixer

Thread 1 hit Catchpoint 2 (signal SIGSEGV), 0x0000000007642a4b in ?? ()
1: x/i $pc
=> 0x7642a4b:   movzwl 0x11000000(%r12d,%eax,1),%ebx
2: /x $rsp = 0x115f318
x86 pc 7642a4b mac pc 40c9db18
Pattern not found.
(gdb) p /x $r12d+$eax+1
$1 = 0xffffffff

The mixer value looks wrong

The second crash is during audio InitOutputDevice delegation

warning: B2: 10/20/20 14:30:47:577 AudioDispatch params 0dbee066 (size 4), what -1
warning: B2: 10/20/20 14:30:47:585 AudioDispatch params 0dbee0b4 (size 4), what 1
warning: B2: 10/20/20 14:30:47:592  InitOutputDevice

With negations disabled, sse3+ reenabled audion still works, although the crashes on second launch are still happening

Slirp is broken but tap works

looking at fneg, it uses an rdata immediate, I'll have to double check that it has the right value implied by the rdata reference and if not why not.

capstone disassembly for op_fneg_FD_F0:
0x2d40:      movsd (%rbx), %xmm0                            f2 0f 10 03
0x2d44:      xorpd 0x10(%rip), %xmm0                        66 0f 57 05 10 00 00 00
0x2d4c:      movsd %xmm0, 0x1008a8(%r15)                    f2 41 0f 11 87 a8 08 10 00
0x2d55:       retq                                          c3
0x2d56:       nopw %cs:(%rax, %rax)                         66 2e 0f 1f 84 00 00 00 00 00

DEFINE_GEN(gen_op_fneg_FD_F0,void,(void))
#ifdef DYNGEN_IMPL
#define HAVE_gen_op_fneg_FD_F0
{
    static const uint8 op_fneg_FD_F0_code[] = {
       0xf2, 0x0f, 0x10, 0x03, 0x66, 0x0f, 0x57, 0x05, 0x10, 0x00, 0x00, 0x00,
       0xf2, 0x41, 0x0f, 0x11, 0x87, 0xa8, 0x08, 0x10, 0x00
    };
    copy_block(op_fneg_FD_F0_code, 21);
    assert(global_dot_rdata != NULL);
  assert( ((long)((uintptr)global_dot_rdata & 0xffffffff) - (uintptr)(code_ptr() + 8) + 16 -4) <= 0x7fffffff || ((long)((uintptr)global_dot_rdata & 0xffffffff) - (uintptr)(code_ptr() + 8) + 16 -4) >= 0xffffffff80000000);
    *(uint32_t *)(code_ptr() + 8) += (uint32_t)((long)((uintptr)global_dot_rdata & 0xffffffff) - (uintptr)(code_ptr() + 8) + 16 -4);
    inc_code_ptr(21);
}
#endif

and something else in the first set, maybe abs/negative abs is causing one of the related problems?

specifically negation and one or more of the negative multiply-adds

It's just the FPU instructions. There are three sets of them in the case: unary, binary, and ternary, and having any one or more of them enabled causes some sound Audion decoding weirdness, though the character of the weirdness changes.

They have a common pattern:

• n relevant loads from ppc fpr to synthetic regs dg.gen_load_F?_FPR
• gen math operation specific to the instruction e.g. dg.gen_fadd_FD_F0_F1
• store sythetic reg fd to ppc fpr
• if rc, record cr1

Audion decoding problem: shotgun debugged down to the instructions in the ppc-translate.cpp big instruction switch, somewhere between :1316 #if PPC_ENABLE_FPU_EXCEPTIONS == 0 various floating points, and :1408 STVXL

• When splitting a basic block because we are following a jump into the middle of it, remember to apply the visited flags properly to the new block if appropriate

I started down the path of implementing a JIT compare mode, but got stuck because I can't make sense of how much code the JIT's case's main loop in powerpc_cpu::execute is running at once with even block chaining off, and also I'm running into bad side effects of special flags being handled on an incorrect state because of the state reset for the second run of the same code.

And interaction with side effects outside the boundary of what's deemed machine state, such as I/O (disk, timers, etc) and various kinds of emul op would need to be caught by some kind of simulation check that does not actually do those actions

(strategy) I was thinking that what it would be handy, when trying to locate problems in cases where JIT is behaving badly but JIT-disabled is working fine, to have a way to use both CPU emulation implementations in the same run and compare the results of execution in each to figure out where things diverge. The granularity would have to be something that could possibly work for the JIT, say comparing before each basic block.

This isn't super straightforward. Naively all of emulated system memory is part of machine state, that's a lot to compare after every basic block.

Yes, that's correct.

One of the items on my to-do list is to set up a Vagrant config for Windows to simplify the process of testing in it if you don't normally deal with it.

One way to get a 'Windows machine': Microsoft provides VM images with 90-day unactivated trial copies of the Windows for IE/Edge browser testing, but these that will run software other than the browser provided that it works without installing additional OS components that require activation. The license permits non-commercial testing use and does not specify browser use particularly.

If you don't already have a virtualization software installed that you prefer I recommend VirtualBox, but if you're on a Linux distro that doesn't package VirtualBox and does package a KVM frontend like virt-manager, you may want to figure out how to use that instead. https://github.com/lentinj/ie-vm (These are referred to as 'modern.ie' VMs because before the era of Edge they used to be distributed from Microsoft's modern.ie site)

See PR #136 and #137

This is a set of changes to get the emaculation codebase building in MSYS2. It is mostly changes cherry picked from out of kanjitalk755's master.

This is a sort of minimal set. Building is not to say working, this is a starting point for you.

If you have some other way of building that supports e.g. your -mno-cygwin etc. that you want to stay compatible with you'll need to rework this to maintain compatibility.

Here's an Appveyor configuration to build using MSYS2

Wait, is the Windows code in the master branch here actually in a buildable state at all?

++ -I../include -I. -I../CrossPlatform -I../uae_cpu -I../slirp -DHAVE_CONFIG_H  -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2 -I/mingw32/include/SDL2 -Dmain=SDL_main -c ../main.cpp -o obj/main.o
g++ -I../include -I. -I../CrossPlatform -I../uae_cpu -I../slirp -DHAVE_CONFIG_H  -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2 -I/mingw32/include/SDL2 -Dmain=SDL_main -c main_windows.cpp -o obj/main_windows.o
g++ -I../include -I. -I../CrossPlatform -I../uae_cpu -I../slirp -DHAVE_CONFIG_H  -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2 -I/mingw32/include/SDL2 -Dmain=SDL_main -c ../prefs.cpp -o obj/prefs.o
g++ -I../include -I. -I../CrossPlatform -I../uae_cpu -I../slirp -DHAVE_CONFIG_H  -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2 -I/mingw32/include/SDL2 -Dmain=SDL_main -c ../prefs_items.cpp -o obj/prefs_items.o
In file included from C:/msys64/mingw32/i686-w64-mingw32/include/minwindef.h:163,
                 from C:/msys64/mingw32/i686-w64-mingw32/include/windef.h:9,
                 from C:/msys64/mingw32/i686-w64-mingw32/include/windows.h:69,
                 from sysdeps.h:50,
                 from main_windows.cpp:21:
main_windows.cpp:66:36: error: cannot initialize array of 'wchar_t' from a string literal with type array of 'char'
   66 | const TCHAR ROM_FILE_NAME[] = TEXT("ROM");
      |                                    ^~~~~
main_windows.cpp: In function 'int SDL_main(int, char**)':
main_windows.cpp:367:38: error: cannot convert 'const wchar_t*' to 'LPCSTR' {aka 'const char*'}
  367 |  HANDLE rom_fh = CreateFile(rom_path ? rom_path.get() : ROM_FILE_NAME,
      |                             ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                      |
      |                                      const wchar_t*
In file included from C:/msys64/mingw32/i686-w64-mingw32/include/winbase.h:18,
                 from C:/msys64/mingw32/i686-w64-mingw32/include/windows.h:70,
                 from sysdeps.h:50,
                 from main_windows.cpp:21:
C:/msys64/mingw32/i686-w64-mingw32/include/fileapi.h:53:48: note:   initializing argument 1 of 'void* CreateFileA(LPCSTR, DWORD, DWORD, LPSECURITY_ATTRIBUTES, DWORD, DWORD, HANDLE)'
   53 |   WINBASEAPI HANDLE WINAPI CreateFileA (LPCSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile);
      |                                         ~~~~~~~^~~~~~~~~~
make: *** [Makefile:148: obj/main_windows.o] Error 1