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

[K.Prasad]

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.

'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
panic due to changes in an implementation detail internal to the kernel
without any perceptible difference in functionality.

Thanks,
K.Prasad

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/