[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 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
    >>>> 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

    > 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.


     \ /
      Last update: 2010-02-15 20:41    [W:0.047 / U:185.156 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site