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,
The problem I believe is very reproducable.
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

And when I do the steps mentioned when in a console I get a message waiting for gdb to attach
I'm familiar with kgdb, have been using it for years & know enough to be sure this is undesired behaviour.

Jason Wessel wrote:
> Denis Joseph Barrow wrote:
>> Hi ladies/gentlemen,
>> The kernel I'm running gdb with is 2.6.27-rc4
>> The false sigtrap is occuring in ia32_sysenter_target in arch/x86/kernel/entry_32.S:303
>> when gdb is stepped from the user process as described below
>>
>>   
> 
> Your example does not indicate how or why you setup kgdb.  kgdb can be
> compiled into the kernel, but it should not have any effect what so ever
> unless it is configured for use because it will not register to receive
> any of the breakpoint or single stepping traps.
> 
> Perhaps there is more to the description of your problem?
> 
> Jason.
> 
>> To reproduce
>> compile kernel with kgdb support 
>> compile my randsleep program attached using the .mk script
>> as root
>> attach randsleep to an idle serial port e.g. /dev/ttyS0 by typing
>> randsleep /dev/ttyS0
>> from another bash shell type
>> ps -aux | grep randsleep
>>
>> gdb ./randsleep
>> attach <pid of randsleep>
>>
>> You should get messages from gdb like
>> Attaching to program: /home/djbarrow/devel2/randsleep/randsleep, process 6397
>> Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
>> Loaded symbols for /lib/tls/i686/cmov/libc.so.6
>> Reading symbols from /lib/ld-linux.so.2...done.
>> Loaded symbols for /lib/ld-linux.so.2
>> 0xb7fda430 in __kernel_vsyscall ()
>>
>> Now type step.
>>
>> The machine is now hung until gdb attaches remotely.
>>
>>
>>   


-- 
best regards,
D.J. Barrow