[lkml]   [2009]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 02/11] x86 architecture implementation of Hardware Breakpoint interfaces

    * K.Prasad <> wrote:

    > Even if #3 was implemented as described, we would still retain
    > a majority of the complexity in balance_kernel_vs_user() to
    > check newer tasks with requests for breakpoint registers.

    Not if it's implemented in a really simple way:

    Kernel gets debug registers in db4..db3..db2..db1 order, and its
    allocation is essentially hardcoded - i.e. we dont try to be

    User-space (gdb) on the other hand will try to allocate in the
    db1..db2..db3..db4 order.

    Maintain a 'max debug register index' value driven by ptrace and
    maintain a 'min debug register index' driven by kernel-space
    hw-breakpoint allocations.

    If they meet somewhere inbetween then we have overcommit which
    we dont allow. In all other cases (which i proffer covers 100%
    of the sane cases) they will mix amicably.

    Sure, user-space can in principle do db4..db3..db2..db1
    allocations as well, but it would be silly and GDB does not do

    So there's no real overlap between register usage - hence no
    need for any complex scheduling smarts. Keep it simple first,
    and only add complexity when it's justified.

    [ for the special case of an architecture having just a single
    debug register this will bring the expected behavior of either
    allowing gdb to use the breakpoint or allowing the kernel to
    use it. ]


     \ /
      Last update: 2009-03-11 14:13    [W:0.038 / U:2.632 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site