https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #43 from tjb troyb@us.ibm.com --- I dug a little into the ptrace/hw breakpoint stuff tonight. One thing which looked suspicious to me from the traces I posted was that the program crashed nearly immediately after a poke of 0x11110055 to dr7. The first klog in the old kernel code showed breakpoint disabled and skipped during this call. However the new kernel code will always set the breakpoint. The problem might be that poking 0x11110055 to dr7 before the breakpoing address registers are even set is enabling breakpoints with either uninitialized or unwanted tracepoints. To test this out I updated server/ptrace.c to zero out the breakpoint addressess (0 should never be hit) before poking the 0x11110055.
. . .
ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(0), 0x00000000 ); ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(1), 0x00000000 ); ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(2), 0x00000000 ); ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(3), 0x00000000 ); ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(6), 0x00000000 ); ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(7), 0x11110055 );
switch (context->cpu)
. . .
and voila now BO2 starts with the new kernel breakpoint behavior introduced in Linux 4.19. This should also work fine with previous breakpoint behavior in Linux <4.19. I don't know if this is the "right" fix but it does appear that the previous kernel breakpoint behavior may have been covering up a wine bug where it was enabling breakpoints in dr7 without first configuring the breakpoint addresses, i.e. the new kernel code may have exposed a latent bug in wine.