Re: [Kgdb-bugreport] [PATCH][3/3] Update CVS KGDB's wrt connect /detach

From: George Anzinger
Date: Fri Feb 27 2004 - 17:09:45 EST


Tom Rini wrote:
On Thu, Feb 26, 2004 at 05:57:27PM -0800, George Anzinger wrote:

Tom Rini wrote:

- Connect to a waiting kernel, continue/^C/disconnect/reconnect.
- Connect to a running kernel, continue/^C/disconnect/reconnect.
- Once connected and running, ^C/hit breakpoint and
disconnect/reconnect.
- Once connected, set a breakpoint, kill gdb and hit the breakpoint and
reconnect.
- Once connected and running, kill gdb and reconnect.

The last two aren't as "fast" as I might like, but they're the "gdb went
away in an ungraceful manner" situations, so I think it's OK. In the
first (breakpoint hit, no gdb) I end up having to issue a few continues
to get moving again, but it's a one-time event.

What are you referring to as "continues". How is this different from connect to a waiting kernel? Usually this would be the end of the session. If you are going to continue from here something needs to be done with the breakpoint that gdb does not know about. If kgdb can remove them, well fine, except your stopped on one. If you remove it, there could be some confusion as to why you are in the debugger. This would be a fine time for a note to the user from kgdb. It is too bad that the interface does not admit to such a thing.


OK, I've rechecked the senarios, and the only time gdb/kgdb seems a bit
confused is when gdb sets a bpt / dies / bpt is triggered. It looks
like this (on gdb reattaching to the now stuck host, gdb 6.0):
Remote debugging using /dev/ttyS0
Sending packet: $qPassSignals:0e;10;14;17;1a;1b;1c;21;24;25;4c;#df...Ack
Packet received: Packet qPassSignals (pass-signals) is NOT supported
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: QC00000000000000d0
Sending packet: $qOffsets#4b...Ack
Packet received: Sending packet: $?#3f...Ack

<- At this point, kgdb calls remove_all_break() ->
I don't know this code, but if the current PC is at a given BP+1 you may need to back up the PC to point to the, now replaced, instruction. You could verify this by looking, at this point, at what gdb has for the PC. Odds are that it is either mid instruction or after the instruction that was replaced by the BP (depends on the relative length of the BP instruction and the replaced instruction).

-g

Packet received: S05
Sending packet: $Hgd0#43...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: 27000000ff0100007b000000c0feffbf703f55d6bc3f55d6c0feffbfd4fdffbf8a4815c08202000060000000680000007b0069d77b000000ffff0000ffff0000
0xc015488a in sys_mkdir (Sending packet: $m27,8#3a...Ack
Packet received: E22
Sending packet: $m27,8#3a...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
pathname=0x27 <Address 0x27 out of bounds>, mode=-1073742144) at fs/namei.c:1533
1533 tmp = getname(pathname);
Sending packet: $qSymbol::#5b...Ack
Packet received: Packet qSymbol (symbol-lookup) is NOT supported

<- continue ->

Continuing.
Sending packet: $Hsd0#4f...Ack
Packet received: Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T0bthread:00000000000000d0;
[New Thread 208]
Sending packet: $g#67...Ack
Packet received: 27000000ff0100007b000000c0feffbf703f55d6bd3f55d6c0feffbfd4fdffbf8b4815c08602010060000000680000007b0069d77b000000ffff0000ffff0000

Program received signal SIGSEGV, Segmentation fault.
0xc015488b in sys_mkdir (Sending packet: $m27,8#3a...Ack
Packet received: E22
Sending packet: $m27,8#3a...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
pathname=0x27 <Address 0x27 out of bounds>, mode=-1073742144) at fs/namei.c:1533
1533 tmp = getname(pathname);

<- continue ->

Continuing.
Sending packet: $C0b#d5...Ack
Packet received: Can't send signals to this remote system. SIGSEGV not sent.
Sending packet: $c#63...Ack
Packet received: T05thread:00000000000000d0;
Sending packet: $g#67...Ack
Packet received: 27000000ff0100007b000000c0feffbf703f55d6bd3f55d6c0feffbfd4fdffbf8b4815c08602010060000000680000007b0069d77b000000ffff0000ffff0000

Program received signal SIGTRAP, Trace/breakpoint trap.
0xc015488b in sys_mkdir (Sending packet: $m27,8#3a...Ack
Packet received: E22
Sending packet: $m27,8#3a...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
Sending packet: $m27,1#33...Ack
Packet received: E22
pathname=0x27 <Address 0x27 out of bounds>, mode=-1073742144) at fs/namei.c:1533
1533 tmp = getname(pathname);

<- continue ->

Continuing.
Sending packet: $c#63...Ack

<- From here, the system is OK again ->

remote_interrupt called
remote_stop called
Packet received: T05thread:0000000000008000;
[New Thread 32768]
Sending packet: $g#67...Ack
Packet received: 0100000004000000000000000400000068df28c06cdf28c080000000809a28c05afd12c00200000060000000680000007b0010c07b000000ffff0000ffff0000

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 32768]
breakpoint () at kernel/kgdb.c:1088
1088 atomic_set(&kgdb_setting_breakpoint, 0);
Sending packet: $D#44...Ack
Packet received: OK
Ending remote debugging.


--
George Anzinger george@xxxxxxxxxx
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/