[lkml]   [2006]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[RFC PATCH 0/4] utrace: new modular infrastructure for user debug/tracing
    I have been working on for a while, and imagining for much longer,
    replacing ptrace from the ground up. This is what I've come up with so
    far, and I'm looking for some reactions on the direction. What I'm
    proposing here is a substrate for doing wonderful new things, and I don't
    yet have something built on top of it to demonstrate wonderful things.
    This is intended to make it easy for lots of folks to whip up new things
    and show what fancy business is possible and worthwhile.

    I've separated this into four successive patches in hopes it makes it
    easier to read the patches. The intent is that each intermediate patch
    yields a kernel tree that compiles and works, though after the first patch
    and before the last you get ENOSYS from any ptrace call. Patch #1 wipes
    out ptrace and its cruft from the bowels of the kernel. Patch #2 converts
    the architecture-specific ptrace guts into the architecture-specific guts
    for the new thing. Patch #3 is the crux of it, the new layer for writing
    debugging interfaces. Patch #4 implements ptrace with user ABI
    compatibility in terms of that layer.

    These patches are relative to; I will shortly rebase to the
    current 2.6.17ish tree, and post updated patches. I don't think the old
    base will make it any harder to review the new code in the patches or its
    core design and implementation choices.

    There are some known loose ends in the code. I am working on those and
    will have more updates along with the rebase in a few days. I am seeking
    feedback on the patches now to identify more issues I have not already
    noted in the code.

    These changes require some small porting work for each architecture. In
    these patches, I have done the architecture work only for i386, x86_64, and
    powerpc. The machine-specific work is quite small and straightforward for
    anyone even mildly familiar with the architecture in question. It consists
    mainly of rearranging the existing architecture code used for ptrace into
    some new functions. There should be no need for new assembly hacking or
    anything like that. I was able to do the powerpc support in a couple of
    hours, and am not any kind of expert on ppc (and took quite a bit longer
    just to get myself able to build and boot ppc kernels). Anyone interested
    in doing the architecture support for another machine, please contact me
    and I'll be glad to help. The steps might already be fairly obvious from
    reading the arch/ changes in these patches.

    At you can always find the current state
    of this work. There you can also find a small test suite I use, and an
    example module demonstrating a novel feature implemented very cheaply using
    the new infrastructure. Please send feedback to me at <>.

    I've tested the new kernel APIs directly with the aforementioned (tiny)
    test suite, and tested them more thoroughly by testing the ptrace
    compatibility implementation based on them. That I've tested using the gdb
    test suite, on x86_64 and ppc64 for both 32-bit and 64-bit userland
    (including both 32-bit and 64-bit gdb's debugging 32-bit processes on the
    64-bit kernel), and on i386. I have not tested the ppc32 kernel, but it
    builds and the changed code is mostly shared with the ppc64 code that does
    work, so it has a decent chance. (For other architectures, some work is
    still required even to get the kernel building again.)


    This series of patches revamps the support for user process debugging
    from the ground up, replacing the old ptrace support completely.

    Two major problems with ptrace are its interface and its implementation.

    The low-level code for tracing core events is directly tied into the
    implementation of the ptrace system call interface. Machine-dependent
    code for accessing registers and controlling single-stepping is
    intermingled with core implementation details that are actually
    machine-independent and repeated across arch directories. ptrace
    interferes with the normal parent-child linkage, introducing many
    corner cases that have caused trouble in the past.

    The shortcomings of ptrace as a user-mode interface for debugging are
    many, and well-known to those who have worked with it from the userland
    side, or been involved in fixing and maintaining it in the kernel. The
    system call interface is clunky to use and to extend, and makes it
    difficult to reduce the overhead of doing several operations and of
    transferring large amounts of data. There is no way for more than one
    party to trace a process. The reporting model using SIGCHLD and wait4
    is tricky to use reliably from userland, and especially hard to
    integrate with other kinds of event loop. Thread event reporting is
    heavy-weight and not specified with good granularity: in practice a
    traced thread stops for everything.

    The old ptrace implementation is removed entirely and replaced with a
    modular interface layer that provides user debugging and tracing
    functionality separate from any single userland interface. Rather than
    trying to come up with a single new interface to replace ptrace, this
    provides a platform for higher-level code in kernel modules to provide
    userland interfaces for tracing and debugging. The ptrace system call
    is provided for compatibility, written on top of the new modular layer.

    Currently there are these four patches:

    [PATCH 1] utrace: tracehook (die, ptrace, die)
    [PATCH 2] utrace: register sets
    [PATCH 3] utrace core
    [PATCH 4] utrace: ptrace compatibility

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-14 01:12    [W:0.026 / U:51.636 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site