The patch I sent is not yet included the kgdb stream because I was
waiting for further comment. I do not see any issues however in the
case that you describe, so I will describe how I tested it and then
perhaps you can explain further the case that does not work.
Given that I still had your test program, I used it to set a
breakpoint at read(), after performing an attach as you described
previous with attaching to the running process. At this point kgdboc
is loaded and configured.
gdb commands:
att PID_OF_randsleep
break read
continue
At this point to hit the breakpoint, I had to type some input on the
ttyS0 which randsleep where randsleep was connected. At that point I
was able to step the system call with enough "si" commands. In the
example shown below I did have to provide some more input after the
"si" for address 0xffffe419 so that the system call would come out of
the sleep state because it happened to be a blocking read.
Example:
(gdb) continue
Continuing.
Breakpoint 1, 0x08056b30 in read ()
(gdb) si
0x08056b38 in read ()
(gdb)
0x08056b3a in __read_nocancel ()
(gdb)
0x08056b3b in __read_nocancel ()
(gdb)
0x08056b3f in __read_nocancel ()
(gdb)
0x08056b43 in __read_nocancel ()
(gdb)
0x08056b47 in __read_nocancel ()
(gdb)
0x08056b4c in __read_nocancel ()
(gdb)
0xffffe414 in __kernel_vsyscall ()
(gdb) disas $pc $pc+8
Dump of assembler code from 0xffffe414 to 0xffffe41c:
0xffffe414 <__kernel_vsyscall+0>: push %ecx
0xffffe415 <__kernel_vsyscall+1>: push %edx
0xffffe416 <__kernel_vsyscall+2>: push %ebp
0xffffe417 <__kernel_vsyscall+3>: mov %esp,%ebp
0xffffe419 <__kernel_vsyscall+5>: sysenter
0xffffe41b <__kernel_vsyscall+7>: nop
End of assembler dump.
(gdb) si
0xffffe415 in __kernel_vsyscall ()
(gdb)
0xffffe416 in __kernel_vsyscall ()
(gdb)
0xffffe417 in __kernel_vsyscall ()
(gdb)
0xffffe419 in __kernel_vsyscall ()
(gdb)
0xffffe424 in __kernel_vsyscall ()
(gdb)
At least this case ...
