[lkml]   [2008]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] Merkey's Kernel Debugger
    > Christoph Lameter wrote:
    >> Stefan Richter wrote:
    >>> Christoph Lameter wrote:
    >>>> The competing implementation is kdb not kgdb. kgdb is just a stub for
    >>>> remote
    >>>> debugging using gdb. kdb is an in-kernel debugger like the one
    >>>> proposed here.
    >>> Is there work underway to get kdb merged? (I'm just asking because I
    >>> don't know; I personally don't need kdb nor mdb.)
    >> KDB still exists in patches but the merge effort was given up when Linus
    >> stated that he did not want a kernel debugger. No problem to start merge
    >> attempts again AFAICT. Jay?
    > To merge KDB or any other RAS tools, you need to deal with kdump. Kdump
    > hijack panic() before the die calling chain. For KDB or a RAS tool to
    > work, an infrastructure such as the "add new notifier function" by
    > Takenori Nagano should be in place.
    > His last attempt fell short, in my opinion, was partly due to his
    > "[PATCH 3/3] Move crash_kexec() into panic_notifier" did not do what it
    > meant to do: to fit kexec/kdump into the new infrastructure. That is
    > not fatal; it can be fixed to make it right. If community is interested
    > in getting a kernel debugger to the kernel, we can continue Takenori's
    > work. Once the infrastructure is accepted, then merging KDB or any other
    > kernel debugger will make sense.
    > Regards,
    > - jay

    As I look through entry_32.S and traps_32.c I do not see where kdump is
    hooking the notify_die handler which would intercept calls to a debugger.

    Where does kdump hook this path?



     \ /
      Last update: 2008-08-07 21:59    [W:4.022 / U:0.108 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site