[lkml]   [2008]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [git pull] kgdb-light -v10
    Andi Kleen wrote:
    >> We might be best served to add a comment to explain the purpose of
    >> kgdb_arch_pc() and put it in the optional implementation function
    >> headers in include/linux/kgdb.h
    >> On some archs certain exceptions do not report the address that the
    >> exception occurred at when you call instruction_pointer(). This optional
    >> function allows for an arch to perform a "fixup" to get the address the
    >> exception actually occurred at.
    > Shouldn't that be handled in the remote gdb?

    No this is a kgdb integrity check.

    Basically when you reach this chunk of code it is before the hand off
    to the source debugger. We cannot continue because there was a
    breakpoint in a part of the system kgdb was using while doing its
    normal work. The reality is that KGDB is not self contained. It
    relies on some external I/O methods, atomic page fault handling and
    some other pieces. If you take an exception there, the kgdb integrity
    check absolutely needs to fail.

    It was the source of some great pain for folks who tried to use kgdb
    for more than an inspection tool. There are some parts of the system
    you cannot debug.

    >> Kgdb requires the actual exception address so a sanity check can be
    >> performed to make sure kgdb did not hit an exception while in a chunk of
    >> code kgdb requires for its functionality. If you hit one of these
    > That was for the old longjmp checks, but that code is long gone isn't it
    > and replacement with standard __ex_table handling.

    This has nothing to do with the long jump

    >> conditions kgdb makes its best attempt to try to "patch the wound"
    >> inflicted by shooting yourself but at least you get notified vs a silent
    >> hang :-)
    > In what cases is that still needed?

    This is a totally stupid test case but it should illustrate the problem.

    - connect to kgdb
    - place a break point at kgdb_disable_hw_debug()
    - continue
    - Now try to break in again

    You will see the kgdb integrity check fail because you put a
    breakpoint in a place that kgdb actually needs to perform its work.
    In this case kgdb will clean up the exception and restore operation
    and you will be ok. The kgdboc has a much smaller swath of code that
    you cannot debug vs something like kgdboe where there are lot more
    places you cannot debug due to the amount of code to services the
    ethernet device, irq sync etc...

    This check is absolutely required to help prevent silent death via
    dumb breakpoints or stepping around in random places (which is ill
    advised anyway).


     \ /
      Last update: 2008-02-12 15:39    [W:0.024 / U:74.996 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site