[lkml]   [2007]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 0/2] x86, ptrace: support for branch trace store(BTS)
    > Cool.  It's been on my list to look into exposing those features
    > somehow. I hadn't planned on doing it until after the utrace stuff
    > settles and there is a more coherent interface context in which to do
    > it.

    I'm looking very much forward to utrace. From what I read so far, this is
    a much nicer interface.
    I would expect that this feature, together with all other ptrace extensions,
    would need to be adapted to utrace, once that is in.

    > If they are tackling the MSR hacking and context switch and so forth,
    > I'd like to see them start out by just adding block-step
    > (debugctlmsr.btf) with the PTRACE_SINGLEBLOCK interface as ia64 has.
    > That should lay some of the same groundwork needed here, but is much
    > simpler.

    There seems to be support for block stepping in arch/x86/kernel/step.c,
    which is used by kernel/ptrace.c.

    This is now another user for the DEBUGCTL MSR; the access needs to be
    synchronized. I'll look into it.

    > I am not really in favor of this new ptrace interface. I think they
    > should look around across arch's and think about sane general-purpose
    > interfaces for features of this kind that might be built with some
    > commonality across machines.

    I looked at the include/asm-*/ptrace.h files and some arch/*/kernel/ptrace.c
    files. Most arch's support a few variants of GET<whatever>REGS.
    Most implementations simply copy_to_user the kernel structures for the
    requested registers.

    Sparc64 needs to convert pointer sizes and defines the returned struct
    directly in the implementation.
    Xtensa provides access to an array of FP regs of varying size. They provide
    a ptrace command to query for the size, but otherwise also copy_to_user
    the entire array.

    I have not found any arch that does anything more fancy than return a single
    integer value or an array of registers.
    In all cases, the command carries enough information to interpret the result.

    In our case, the array we're querying for can be rather big and
    typically only some
    of the information is interesting. The data we return is inhomogeneous.

    The former may be true for register arrays as well, but they are
    typically small
    enough. The latter would compare to a general GETREGS command that returns
    all registers in a self-describing format (that might be an
    interesting extension, if
    one got tired of yet another GET<new-type-of>REGS command).

    Instead of providing the entire array in one command, we introduced commands to
    handle that array.
    Instead of carrying the information how to interpret the result in the
    command itself,
    we provide that information directly in the result.

    I would argue that this interface may be directly (re)used and
    extended by other arch's.

    Do you have specific concerns regarding the interface?

    > Also do it in a layered way from
    > low-level, with something usable for kernel-mode too.

    To disable cpl0-filtering should be fairly easy; we would simply clear
    the cpl-bit
    in the debugctl_mask. This way, you can trace the kernel
    part of the application, but you would still debug the application.
    You could call the ptrace_bts_ functions directly or we might add a new set of
    interface functions that simply forward the request (or the other way round).

    To provide a per-cpu trace instead of a per-thread trace would be a
    completely new
    feature that only has the configuration part in common with our patch.

    What did you have in mind when you asked for kernel-mode support?

    thanks and regards,

     \ /
      Last update: 2007-12-03 14:55    [W:0.025 / U:4.744 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site