Re: getting false SIGTRAP breakpoints in kernel i.e. kernel hung unless gdb remotely attached on x86 & cont is issued

[Denis Joseph Barrow <D.Barow@option.com>]

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