Bug 21332 - Regression in single stepping over hardware breakpoint (Wine)
Regression in single stepping over hardware breakpoint (Wine)
Status: CLOSED CODE_FIX
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64
All Linux
: P1 normal
Assigned To: platform_x86_64@kernel-bugs.osdl.org
http://git.kernel.org/?p=linux/kernel...
:
: 21932 (view as bug list)
Depends on:
Blocks: 16444
  Show dependency treegraph
 
Reported: 2010-10-27 23:41 UTC by Michael Stefaniuc
Modified: 2010-12-05 19:55 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.36
Tree: Mainline
Regression: Yes


Attachments

Description Michael Stefaniuc 2010-10-27 23:41:36 UTC
There is a regression between 2.6.35 and 2.6.36 for 32bit Wine in the Wine test checking the single stepping over hardware breakpoints:
/home/michi/work/wine/tools/runtest -q -P wine -M ntdll.dll -T ../../.. -p ntdll_test.exe.so /home/michi/work/wine/dlls/ntdll/tests/exception.c && touch exception.ok
exception.c:585: Test failed: eip is wrong: 340002 instead of 340001
exception.c:587: Test failed: B0 flag is not set in Dr6
exception.c:588: Test failed: BS flag is set in Dr6
exception.c:593: Test failed: eip is wrong: 7ed569d3 instead of 340002
make: *** [exception.ok] Error 4

All those tests are in bpx_handler() http://source.winehq.org/git/wine.git/?a=blob;f=dlls/ntdll/tests/exception.c;h=701b6bba091dddce724075dc41dd2ab407f28ac4;hb=HEAD#l559

A regression test gives:
0c4519e825c9e2b6a8310deff8582f8c35bfbba9 is the first bad commit
commit 0c4519e825c9e2b6a8310deff8582f8c35bfbba9
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date:   Thu Jun 24 21:21:27 2010 +0200

    x86: Set resume bit before returning from breakpoint exception

    Instruction breakpoints trigger before the instruction executes,
    and returning back from the breakpoint handler brings us again
    to the instruction that breakpointed. This naturally bring to
    a breakpoint recursion.

    To solve this, x86 has the Resume Bit trick. When the cpu flags
    have the RF flag set, the next instruction won't trigger any
    instruction breakpoint, and once this instruction is executed,
    RF is cleared back.

    This let's us jump back to the instruction that triggered the
    breakpoint without recursion.

    Use this when an instruction breakpoint triggers.

    Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Prasad <prasad@linux.vnet.ibm.com>
    Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Jason Wessel <jason.wessel@windriver.com>

:040000 040000 2eae1fa5f90b141d60fe28a971a618e9c0b1a232 e27fd94a1beb10e3688d555bd74c888b6a310293 M      arch

Reverting this patch on top of 2.6.36 makes the problem go away.

The problem is 100% reproducible and I see it in 32bit Wine on both 32bit and 64bit Linux. The regression might affect also 64bit Wine but those exception tests aren't compiled for 64bit Wine due to the lack of compiler support for win64 exceptions; so we cannot test it.


Steps to reproduce:
-------------------
Any Wine version wine-1.2 or newer will do (either a tarball from http://sourceforge.net/projects/wine/files/Source/ or from git
   git clone git://source.winehq.org/git/wine.git
./configure
make
cd dlls/ntdll/tests/
make exception.ok

There should be no errors and exception.ok should have been created.

For builds on a x86_64 machine a pretty complete 32bit setup is needed too, but configure will complain. If configure doesn't errors out but produces warnings, those can be safely ignored. It means the dependencies are optional and those aren't needed to reproduce this bug. http://wiki.winehq.org/WineOn64bit has a lot more info on setting this up.
Comment 1 Michael Stefaniuc 2010-10-27 23:58:14 UTC
Addendum to the expected test result:
"There should be no errors and exception.ok should have been created."
That should read: the above errors on lines 585, 587, 588, 593 should not show up. Additionally there should be no error in line 665 as that means the tests didn't run.

While doing the regression test there were two temporary regressions: one could be safely ignored the other produced a test failed in line 665 (the patch from commit 89e45aac42d4 needed to be applied at each bisection point).
Comment 2 Rafael J. Wysocki 2010-10-28 11:15:56 UTC
First-Bad-Commit : 0c4519e825c9e2b6a8310deff8582f8c35bfbba9
Comment 3 Rafael J. Wysocki 2010-11-19 20:24:49 UTC
On Friday, November 19, 2010, Frederic Weisbecker wrote:
> On Fri, Nov 19, 2010 at 12:53:38AM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.35 and 2.6.36.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.35 and 2.6.36.  Please verify if it still should
> > be listed and let the tracking team know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=21332
> > Subject		: Regression in single stepping over hardware breakpoint (Wine)
> > Submitter	: Michael Stefaniuc <mstefani@redhat.com>
> > Date		: 2010-10-27 23:41 (23 days old)
> 
> The fix is in:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
> 	perf/urgent
> 
> 6c0aca288e726405b01dacb12cac556454d34b2a
> ("x86: Ignore trap bits on single step exceptions")
> 
> And should reach mainline soon.
Comment 4 Florian Mickler 2010-12-05 16:50:20 UTC
*** Bug 21932 has been marked as a duplicate of this bug. ***
Comment 5 Rafael J. Wysocki 2010-12-05 19:55:40 UTC
Fixed by commit 6c0aca2 x86: Ignore trap bits on single step exceptions .

Note You need to log in before you can comment on or make changes to this bug.