profile
viewpoint

alamminsalo/orion 289

Cross platform Twitch.tv client

rakslice/leaix 4

AMD am799x (PCnet/Lance) Ethernet network driver for AIX PS/2 1.3, ported from NetBSD 1.1

rakslice/debian_cde 2

build and set up CDE on debian

rakslice/es40 1

A portable emulator for the HP (DEC, Compaq) AlphaServer ES40. I personally forked this to get to the bottom of some concurrency-related crashes with upstream Windows builds, but they seem to already be fixed in this codebase.

rakslice/launchy-sqlite 1

a Launchy plugin for customizable data-driven URL launching using a simple SQLite database

rakslice/alacarte 0

Main Menu

rakslice/appversioner 0

my software update check script for Windows

rakslice/BackgroundMusic 0

Background Music, a macOS audio utility: automatically pause your music, set individual apps' volumes and record system audio. [forked to add per-app panning]

rakslice/BasiliskII_win32 0

This is for the snapshots of Lauri Pesonen's old win32 port of BasiliskII from '99-01 that I could find

rakslice/copyboard 0

a simple text copy board

push eventrakslice/macemu

rakslice

commit sha 3d057c4b0e867be0199b8d3b8d29c65534ec17e2

do not use inline asm for mulhw,mulhwu in gcc 7,8 as it fails to move output

view details

rakslice

commit sha 0511ac7a984037ac509106bd7f39cebb9df5bc10

Merge remote-tracking branch 'raksys4/dyngen_modernization_experiment' into dyngen_modernization_experiment

view details

push time in 2 hours

issue commentrakslice/macemu

Experiment with modernization of dyngen

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.

rakslice

comment created time in 2 hours

issue commentrakslice/macemu

Experiment with modernization of dyngen

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.

rakslice

comment created time in 3 hours

issue commentrakslice/macemu

Experiment with modernization of dyngen

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
rakslice

comment created time in 5 hours

issue commentrakslice/macemu

Experiment with modernization of dyngen

(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).

rakslice

comment created time in 5 hours

issue commentrakslice/macemu

Experiment with modernization of dyngen

(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) 
rakslice

comment created time in 6 hours

push eventrakslice/macemu

rakslice

commit sha 8a31d39fc55e415682962aabaf12ca4023e67081

Windows: add DYNGEN_OP_FLAGS flags for gcc 10 i386

view details

push time in a day

issue commentrakslice/macemu

SheepShaver mystery crash

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

rakslice

comment created time in 2 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

(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
rakslice

comment created time in 3 days

issue commentrakslice/macemu

SheepShaver mystery crash

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.

rakslice

comment created time in 3 days

issue openedrakslice/macemu

SheepShaver mystery crash

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

created time in 3 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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

rakslice

comment created time in 3 days

push eventrakslice/macemu

rakslice

commit sha 74b9ba8ad057b7c332f5157791f80d63abad28b2

allow emitting a no-op jump for the time being, to support op_branch_next_A0's redundant jump instruction at the end

view details

rakslice

commit sha 2137a2de9fa0d6fae3462311d8659090c8bdd42d

need to use the original relocation address when getting a value out of the original text

view details

rakslice

commit sha 3798fd48eb8adf9bb1347c3f3efaa979b4389a35

show i386 coff and elf relocations in the dyngen stdout log output

view details

push time in 3 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

(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
rakslice

comment created time in 3 days

push eventrakslice/macemu

rakslice

commit sha 63037d7cf597be274e5dcc502ace0d151f164683

show i386 jmp_addr code_ptr() settings in the dyngen stdout output log

view details

push time in 4 days

push eventrakslice/macemu

rakslice

commit sha 0129cebaade865a680538ae776febf3d271add5e

more corresponding i386 cases to conditionals where appropriate

view details

rakslice

commit sha c7e59562de7db5faa4ad2d2960df1e7cb1f79b46

avoid problems with partially generated hpp files

view details

rakslice

commit sha af110a4683974e26d81d5046c0435f6e81ce9ca4

fix capstone mode flags use for i386

view details

rakslice

commit sha dee06f5d72a35792944cb43b41a2e8aa05b69ce3

more sorting out HOST_I386 cases for new dyngen stuff; don't try to use x86_64 op_jump_next_A0 special handler

view details

rakslice

commit sha d19bdf79ad16a0e6811a90468c6d59081ee39240

Enable basic block map rearrangement updates to relocations for i386 cases other than mach; added a new function for properly telling whether the original address of a candidate relocation is is in a block we care about according to the map

view details

push time in 4 days

created tagrakslice/macemu

tag20201026

Basilisk II and SheepShaver Macintosh emulators

created time in 4 days

release rakslice/macemu

20201026

released time in 4 days

push eventrakslice/macemu

rakslice

commit sha a14362b18391e6a3e2e774a425f1c74c421f2ec0

Windows: add a critical section for slirp calls to avoid unsafe use from multiple threads

view details

kanjitalk755

commit sha 3ce86cee1f62fd7a1179eec2cf0265872a2da4e4

Merge pull request #63 from rakslice/slirp_critical_section_win Windows: prevent calls to slirp functions from multiple threads concurrently

view details

rakslice

commit sha 0b9b6401d6bd4246b4d58d395974c787ffc108c1

Merge pull request #42 from kanjitalk755/master update kanjitalk755_master

view details

push time in 4 days

PR merged rakslice/macemu

update kanjitalk755_master
+13 -1

0 comment

1 changed file

rakslice

pr closed time in 4 days

PR opened rakslice/macemu

update kanjitalk755_master
+13 -1

0 comment

1 changed file

pr created time in 4 days

issue closedrakslice/macemu

Windows: slirp segfault

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]

closed time in 4 days

rakslice

push eventrakslice/macemu

rakslice

commit sha e326d9ff6d09384bdb52c49cd728d7a4ecc65352

add corresponding i386 cases to conditionals where appropriate; fix typo

view details

push time in 4 days

push eventrakslice/macemu

rakslice

commit sha c03de0bcfc73003fcfe82826afb278c1c10a0cf8

remove errant return in audio component close handler

view details

rakslice

commit sha 2ebc8b8b36c7ed6c428df24b991d6acd17b70ba1

Windows: add a critical section for slirp calls to avoid unsafe use from multiple threads (cherry picked from commit a14362b18391e6a3e2e774a425f1c74c421f2ec0)

view details

rakslice

commit sha 194f683742c2cd3565441cb8b3fc9051b4ce7d61

socket errno define remappings are actually needed; reenable, and undef them first to avoid warnings

view details

push time in 4 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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

rakslice

comment created time in 4 days

issue commentrakslice/macemu

Windows: slirp segfault

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

rakslice

comment created time in 4 days

issue commentrakslice/macemu

slirp crash

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.

rakslice

comment created time in 4 days

issue commentrakslice/macemu

slirp crash

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.

rakslice

comment created time in 4 days

issue commentrakslice/macemu

slirp crash

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

rakslice

comment created time in 4 days

issue openedrakslice/macemu

Make the SheepShaver build process use common files directly

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.

created time in 4 days

GollumEvent

create barnchrakslice/macemu

branch : slirp_critical_section_win

created branch time in 5 days

issue commentrakslice/macemu

slirp crash

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.

rakslice

comment created time in 5 days

issue commentrakslice/macemu

slirp crash

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
rakslice

comment created time in 5 days

issue commentrakslice/macemu

slirp crash

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     }
rakslice

comment created time in 5 days

issue openedrakslice/macemu

screen tearing

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.

created time in 5 days

issue commentrakslice/macemu

slirp crash

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 ?? ()
rakslice

comment created time in 5 days

issue commentrakslice/macemu

slirp crash

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.

rakslice

comment created time in 5 days

issue openedrakslice/macemu

slirp crash

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.

created time in 5 days

created tagrakslice/macemu

tag20201024

Basilisk II and SheepShaver Macintosh emulators

created time in 5 days

release rakslice/macemu

20201024

released time in 5 days

push eventrakslice/macemu

rakslice

commit sha 1892cf0a7ead3be2e8945b9368d39be9db6dc15f

remove errant return in audio component close handler

view details

kanjitalk755

commit sha cc5d99431fb0052404dcd170bc6fedd3e2bcdc37

Merge pull request #62 from rakslice/fix_audio Fix for audio crashes on second playback

view details

push time in 6 days

issue commentemaculation/shoebill

Fix Windows CI

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?

ianfixes

comment created time in 6 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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

rakslice

comment created time in 6 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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

rakslice

comment created time in 6 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

(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.

rakslice

comment created time in 6 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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
rakslice

comment created time in 7 days

issue commentrakslice/macemu

fatal error on second audio playback

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/

rakslice

comment created time in 7 days

issue closedrakslice/macemu

fatal error on second audio playback

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

closed time in 7 days

rakslice

issue commentrakslice/macemu

fatal error on second audio playback

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

rakslice

comment created time in 8 days

issue commentrakslice/macemu

fatal error on second audio playback

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

rakslice

comment created time in 8 days

PR opened kanjitalk755/macemu

Fix for audio crashes on second playback

Fixes rakslice/macemu#38

+1 -1

0 comment

1 changed file

pr created time in 8 days

create barnchrakslice/macemu

branch : fix_audio

created branch time in 8 days

push eventrakslice/macemu

kanjitalk755

commit sha 73f194f422f0cf6363074eb1fde80d89bb401c3f

remove .travis.yml reduce warnings

view details

push time in 8 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

(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.

rakslice

comment created time in 8 days

push eventrakslice/macemu

rakslice

commit sha 5974ae7412efc60f7382e7160502a07f1db46ae0

missing newline

view details

rakslice

commit sha b04298d618a84000cda439e8b199fc61b8754929

fix conditional for elf-specific check

view details

push time in 8 days

push eventrakslice/macemu

rakslice

commit sha 4c5c4698fc488366dec6b40bf8ac66d8a030fb71

fix cleanup code

view details

rakslice

commit sha bf9450ea03ccc95e2aaec0e2aa8d231e0de31ce0

implement missing call dest handling

view details

rakslice

commit sha ed7efc9748dcd534ed4af014827f4f2b24bc47e5

remove use of cxx_demangle with stack buf that is invalid with __cxa_demangle

view details

rakslice

commit sha 7e2ef0864a6087395d5e3cf5bfeb5234777da99b

skip vague linkage .text.foo elf sections

view details

push time in 8 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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).

rakslice

comment created time in 8 days

push eventrakslice/macemu

rakslice

commit sha 8fcea540908b2181bdc07ebd2e394e312fe11810

missing include

view details

rakslice

commit sha 7c5240baa10e5751b29e61287c4431f1d5f31ec9

make op_execute stack fixup win64 specific

view details

rakslice

commit sha dc11dc2025359c6a5eab70accd791af0bf1de875

Merge remote-tracking branch 'raksys4/dyngen_modernization_experiment' into dyngen_modernization_experiment

view details

push time in 8 days

issue commentrakslice/macemu

fatal error on second audio playback

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

rakslice

comment created time in 8 days

issue commentrakslice/macemu

fatal error on second audio playback

Also happens on Linux

rakslice

comment created time in 8 days

push eventrakslice/macemu

kanjitalk755

commit sha 594ba79e51ad64696129a977fd2ab0ca81fbbbe5

remove .travis.yml reduce warnings (cherry picked from commit 73f194f422f0cf6363074eb1fde80d89bb401c3f)

view details

push time in 8 days

push eventrakslice/macemu

rakslice

commit sha c128517391f5e046d54f54e1088b8aafc8f2c649

dyngen: also hook it up for x86_64 ELF, cleanup

view details

push time in 8 days

push eventrakslice/macemu

rakslice

commit sha bacb1f966bfa9b9e6bbbdecc93d71c234d72dda3

dyngen: implemented re-planning the layout of all the blocks and resynthesizing the control flow

view details

push time in 8 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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

rakslice

comment created time in 9 days

create barnchrakslice/macemu

branch : jit_compare_mode

created branch time in 9 days

push eventrakslice/macemu

rakslice

commit sha 5464309c0997b10cee32893bdb312f0d1e20b53c

fix for invalid rdata reference that was breaking floating point negation; removes reloc_increment case

view details

rakslice

commit sha c60cc570a5c47f9a3896b421122a7ad92afbd07d

disable VREFP VRSQRTEFP in JIT because their test results don't match non-JIT

view details

rakslice

commit sha a757edaea9dff1c809e6341deed8dbcd17a069c4

test-powerpc: let vector JIT load store operations from ppc-jit wrap around the end of 32-bit space, for compatibility with test-powerpc using them on powerpc code outside the address space

view details

rakslice

commit sha 72a1513a360118b03b7c29be519125f7d5f7cc8e

cleanup

view details

push time in 9 days

issue commentrakslice/macemu

fatal error on second audio playback

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

rakslice

comment created time in 9 days

issue commentrakslice/macemu

kanjitalk755: fatal error on second audio playback

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.

rakslice

comment created time in 9 days

issue openedrakslice/macemu

fatal error on second audio playback

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

created time in 9 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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
rakslice

comment created time in 10 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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

rakslice

comment created time in 10 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

Slirp is broken but tap works

rakslice

comment created time in 10 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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
rakslice

comment created time in 10 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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

rakslice

comment created time in 10 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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

rakslice

comment created time in 10 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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
rakslice

comment created time in 10 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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

rakslice

comment created time in 10 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

  • 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
rakslice

comment created time in 10 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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.

rakslice

comment created time in 10 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

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

rakslice

comment created time in 13 days

issue commentrakslice/macemu

Experiment with modernization of dyngen

(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.

rakslice

comment created time in 13 days

issue commentemaculation/macemu

Document kernel settings to run SheepShaver in Linux somewhere obvious

Yes, that's correct.

rakslice

comment created time in 14 days

issue commentemaculation/macemu

Enable actual build tests in Windows/Appveyor CI

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.

ianfixes

comment created time in 14 days

issue commentemaculation/macemu

Enable actual build tests in Windows/Appveyor CI

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)

ianfixes

comment created time in 14 days

issue commentemaculation/macemu

Enable actual build tests in Windows/Appveyor CI

See PR #136 and #137

ianfixes

comment created time in 14 days

PR opened emaculation/macemu

Fix Windows build

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.

+179 -70

0 comment

13 changed files

pr created time in 14 days

PR opened emaculation/macemu

Appveyor build configuration using MSYS2

Here's an Appveyor configuration to build using MSYS2

+33 -21

0 comment

1 changed file

pr created time in 14 days

create barnchrakslice/macemu-1

branch : emaculation_windows_fixes

created branch time in 14 days

create barnchrakslice/macemu-1

branch : emaculation_appveyor_msys2

created branch time in 14 days

fork rakslice/macemu-1

Basilisk II and SheepShaver Macintosh emulators, maintained

fork in 14 days

push eventrakslice/macemu

rakslice

commit sha 01078f49dc01fa0671a0be8392536a0da5a26fd2

In SheepShaver GUI don't show JIT checkbox in non-JIT build (cherry picked from commit cd269a9ce1e7440ebfd0e51ee14904009a356df0)

view details

rakslice

commit sha 151a4528a6c9bb63995cdd1fb5637f7e2558390a

changes for buildability under MSYS2 mingw32 (originally in aeb585527d86109e4e2d3b86ed9e71663b39dcf7)

view details

push time in 14 days

push eventrakslice/macemu

rakslice

commit sha 7e7db7a249a682352db355765943439bbd29e621

get prefs_editor_gtk building in mingw32 (merged cherry pick)

view details

Andrew Tonner

commit sha af23bfa34c7be9b70a23184409c725fef90ddf24

In extfs icon creation, ensure that the times on the host file are set correctly; actually allocate space for the other HInfo that set_finfo reads, such as the times (cherry picked from commit 8b44b00da3449164e9a5409ae45223ec989253b7)

view details

rakslice

commit sha 07ca383e2b0c2451f47cc48661a8671c6a7181f6

Use Windows _stat for my_stat

view details

rakslice

commit sha 2a698c71758e8bae254570a390320ff349a70946

Remove tstr from main_windows for buildability

view details

rakslice

commit sha 713330795544972675ef5ea55a31ff6ceecb3dd8

windows: remove _UNICODE from sysdeps; change make links to work with files, not just directories

view details

rakslice

commit sha d1d48d47a3d6910a845d89cdf1579c6cd114e2cf

Windows configure.ac: fix AC_CACHE_CHECK miss case with value with setting in side effecting AC_SUBST which won't get cached (cherry picked from commit 4b93738773bd06aa7dbfc8a1a1cd6edb6f58f87f)

view details

push time in 14 days

push eventrakslice/macemu

rakslice

commit sha 93a5f36448202a260307b73d8afc162f6539290f

remove mno-cygwin from Windows BII GUI builds

view details

push time in 14 days

create barnchrakslice/macemu

branch : emaculation_windows_fixes

created branch time in 14 days

issue commentemaculation/macemu

Enable actual build tests in Windows/Appveyor CI

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
ianfixes

comment created time in 14 days

push eventrakslice/macemu

rakslice

commit sha eaed772601c26588b9b9258c9c3a353a030d0eb9

do before_build gcc runs in the right build environment

view details

push time in 14 days

create barnchrakslice/macemu

branch : emaculation_appveyor_msys2

created branch time in 14 days

create barnchrakslice/macemu

branch : kanjitalk755_master_appveyor_yml_rebase

created branch time in 14 days

more