Re: ptrace single-stepping change breaks Wine

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 12/31/04

  • Next message: Alan Cox: "Re: ide problem..." 
    Date:	Thu, 30 Dec 2004 16:38:21 -0800 (PST)
To: Andi Kleen <ak@muc.de>

    On Fri, 31 Dec 2004, Andi Kleen wrote:
    >
    > Just looking at all this complexiy and thinking about
    > making it work on x86-64 too doesn't exactly give a good
    > feeling in my spine.
    >
    > Not to belittle your archivement Linus but it all looks
    > very overengineered to me.

    Ehh, do you have any _alternatives_?

    > I think such complex instruction emulation games will be
    > hard to maintain and there are very surely bugs in so
    > much subtle code.

    There is no complexity anywhere, and we don't actually emulate any
    instructions at all. The only thing we do is to check _whether_ the
    instruction is a "popf" - we let the CPU do all the work, we just say "ok,
    the instruction will set TF, so we should not touch it afterwards.

    > 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.
     - 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.
     - you couldn't see the instruction after a system call.
     - ptrace returned bogus TF state after a single-step

    > I would love to skip this all on x86-64, but I would prefer
    > to not make the behaviour incompatible to i386.

    I suspect all the code can be shared. In fact, the change to send a
    SIGTRAP directly rather than play around with "ptrace_notify()" etc is
    likely totally architecture-independent apart from the calling convention
    magic, so all of "do_syscall_trace()" could probably be moved into
    kernel/ptrace.c.

    The _only_ real complexity is actually following the silly LDT
    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.

    I assume you have that same prefetch thing on x86-64 already, so if
    anything, you could look at my replacement and see if it would be workable
    to do the prefetch thing too..

    IOW, none of the issues involved are new.

                            Linus
    -
    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/

  • Next message: Alan Cox: "Re: ide problem..."