[Bug 46472] Linux kernel 4.19 breaks startup of BO2 due to change in PTRACE_POKEUSER hw breakpoint behavior

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=46472

--- Comment #43 from tjb <troyb at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.