lkml.org 
[lkml]   [2004]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    Date
    From
    SubjectRe: ptrace single-stepping change breaks Wine
    On Thu, Dec 30, 2004 at 04:38:21PM -0800, Linus Torvalds wrote:
    > > Can someone repeat again what was wrong with the old ptrace
    > > semantics before the initial change that caused all these complex
    > > changes? It seemed to work well for years. How about we just
    > > go back to the old state, revert all the recent ptrace changes
    > > and skip all that?
    >
    > Let me count the ways that were wrong before the changes:
    > - you couldn't debug any code that set TF. Really. ptrace would totally
    > destroy the TF state in the controlled process, so it would do
    > something totally different when debugged.

    Well, tough. I assume people who play with TF themselves know
    how to handle it without debuggers. Really adding instruction
    parsing for such a corner case seems like extreme overkill to me.

    I agree it is not nice, but is it really worth all that complexity
    to hide it?

    > - you couldn't even debug signal handlers, because they were _really_
    > hard to get into unless you knew where they were and put a breakpoint
    > on them.

    Ok I see this as being a problem. But I bet it could be fixed
    much simpler without doing all this complicated and likely-to-be-buggy
    popf parsing you added.

    > - you couldn't see the instruction after a system call.

    Are you sure?

    > - ptrace returned bogus TF state after a single-step

    I am sure all debuggers in existence deal with that (and they will
    need to continue doing so because there are so many old kernels around)

    > descriptors, and we actually do that (badly) in another place: the AMD
    > "prefetch" check does exactly the same thing except it seems to get a few
    > details wrong (looks like it cannot handle 16-bit code), and only works
    > for the current process.

    Yes, it was intentional to simplify it. 16bit code is not supposed
    to use prefetches (and even if they do the probability of faulting
    is pretty small) Also we needed several iterations
    to get all the subtle bugs out (and I bet there are some issues left)

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

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:0.025 / U:153.068 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site