[lkml]   [2008]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: getting false SIGTRAP breakpoints in kernel i.e. kernel hung unless gdb remotely attached on x86 & cont is issued
    Hi Jason,
    Sorry for nitpicking & a big thanks for your patch.
    While this patch stops the big problem, the kernel halting, gdb
    debugging the userland code still doesn't behave correctly
    now. Trying to stepi over a sysenter call in gdb doesn't return
    to the gdb debugger ctrl-c in the debugger still works however.
    Some code probably needs to be also fixed in arch/x86/kernel/ptrace.c
    or ideally the generic kernel/ptrace.c, seeing as this works
    with gdb on a normal kernel it's not a gdb issue even if
    it can be kludge fixed there.
    I'm running GNU gdb 6.8-debian from ubuntu 8.04 hardy heron

    Jason Wessel wrote:
    > Denis Joseph Barrow wrote:
    >> Hi Jason,
    >> The problem I believe is very reproducable.
    > It can be reproduced quite easily as it is a generic problem that
    > appears to have existed for quite a long time.
    >> I'm doing nothing special with kgdb just using it to help me with 3g
    >> modem driver development & my driver wasn't loaded when the problem
    >> occured. I have the following command in my /boot/grub/menu.lst
    >> kernel parameter to enable gdb.
    >> kgdboc=/dev/ttyS0,115200 maxcpus=1
    > This was the key detail that was missing. Along with the program and
    > other gdb details provided the source of the problem was not too hard
    > to track down.
    > When you attach to the running program with ptrace (via gdb), it
    > interrupts the system call and executing the high level "step" will
    > result in gdb executing a number of instruction step operations to try
    > to get back to an instruction which corresponds to the next valid line
    > of high level source code.
    > It was the 3rd or 4th instruction step that jumped back into the
    > kernel space because gdb ultimately tries to single step a system call
    > in your example. For the kernel, single stepping a system call is a
    > special operation in that the system call must appear to complete
    > atomically and the user space ends up on the next user space assembly
    > instruction after the system call. Behind the scenes the kernel
    > executes the system call and tracks this condition.
    > It appears kgdb needs to account for this condition as well, by simply
    > ignoring it when it occurs.
    > Please try the attached patch, as it will hopefully address the
    > problem.
    > Jason.

    best regards,
    D.J. Barrow

     \ /
      Last update: 2008-09-19 14:33    [W:0.024 / U:94.548 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site