[lkml]   [2010]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Regression in ptrace (Wine) starting with 2.6.33-rc1
    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
    >>> 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.


     \ /
      Last update: 2010-02-15 12:59    [W:0.050 / U:69.952 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site