Re: Regression in ptrace (Wine) starting with 2.6.33-rc1

[Michael Stefaniuc <mstefani@redhat.com>]

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