[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.128 / U:2.092 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site