Messages in this thread |  | | | Date | Mon, 15 Feb 2010 20:37:31 +0100 | | From | Michael Stefaniuc <> | | Subject | Re: Regression in ptrace (Wine) starting with 2.6.33-rc1 |
| |
On 02/15/2010 12:57 PM, K.Prasad wrote: > On Mon, Feb 15, 2010 at 12:05:16AM +0100, Michael Stefaniuc wrote: >> On 02/14/2010 09:41 PM, Frederic Weisbecker wrote: >>> On Sun, Feb 14, 2010 at 09:13:06PM +0100, Michael Stefaniuc wrote: >>>> Although Wine will map address 0x0 for DOS programs that isn't the >>>> reason for those tests. Wine has to support games that come with >>>> pointless copy protection schemes that employ that technique. >>> Ah, which kind of protection? >> No clue as I'm not into games. But the wiki has a page for that >> http://wiki.winehq.org/CopyProtection >> >> >>>> Cool, thanks! >>>> Any chance to get that fix into 2.6.33? >>> Yeah. >>> >>> Could you please test the following patch on top of >>> 2.6.33-rc9 ? >> It is an improvement as I don't get an -EINVAL now but the data in DR7 >> is not what was written there and the test fails with: >> exception.c:612: Test failed: failed to set debugregister 7 to 0x155, >> got 2aa >> > > Okay, so this 0x155 written onto ptrace got converted into 0x2AA - > basically all requests to 'locally' enable breakpoints in DR0-DR3 (bits > 0, 2, 4 and 6 of DR7) was converted into a request to 'globally' enable > (bits 1, 3, 5 and 7) breakpoints. Ok, so we have two regressions here: - One fixed by Frederic where breakpoints at address 0x0 weren't allowed (Frederic, can you please upstream that fix?). - The other one with 'locally'/'globally' enabled breakpoints.
> 'Local' breakpoints - here would mean those breakpoints pertaining to a > process that are "automatically cleared on every task switch", which I > presume, happen in cases where TSS registers are used for context > switches (and as I learn is not the case with Linux). > > The hw-breakpoint infrastructure in Linux currently implements > per-process breakpoints using 'global' flag but performs the clean-up > after a task-switch using other methods (such as scheduler hooks through > perf-events). All breakpoint requests (kernel or per-process) > is treated as 'global'. > > We could change this to become 'local' for every local request (but still > cleanup the breakpoints using scheduler hooks like the way we presently > do), but I think this is an implementation detail and that a ptrace user > need not worry about it. Or do you believe that there's any? > > I'm afraid I don't understand your motivation for these read/write tests > on debug control register? Such tests, as in this case, cause unnecessary Like Alexandre said that functionality is used by copy protection mechanisms.
> panic due to changes in an implementation detail internal to the kernel > without any perceptible difference in functionality. The behavior change is user visible and thus part of the ABI and not just an implementation detail.
thanks bye michael
|  |