On Mon, Feb 15, 2010 at 12:05:16AM +0100, Michael Stefaniuc wrote:Ok, so we have two regressions here:On 02/14/2010 09:41 PM, Frederic Weisbecker wrote:On Sun, Feb 14, 2010 at 09:13:06PM +0100, Michael Stefaniuc wrote:No clue as I'm not into games. But the wiki has a page for thatAlthough Wine will map address 0x0 for DOS programs that isn't theAh, which kind of protection?
reason for those tests. Wine has to support games that come with
pointless copy protection schemes that employ that technique.
http://wiki.winehq.org/CopyProtection
It is an improvement as I don't get an -EINVAL now but the data in DR7Cool, thanks!Yeah.
Any chance to get that fix into 2.6.33?
Could you please test the following patch on top of
2.6.33-rc9 ?
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 aLike Alexandre said that functionality is used by copy protection mechanisms.
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 kernelThe behavior change is user visible and thus part of the ABI and not just an implementation detail.
without any perceptible difference in functionality.