Messages in this thread | | | Date | Fri, 27 Feb 2004 08:49:20 -0700 | From | Tom Rini <> | Subject | Re: [Kgdb-bugreport] [PATCH][3/3] Update CVS KGDB's wrt connect / detach |
| |
On Thu, Feb 26, 2004 at 05:57:27PM -0800, George Anzinger wrote:
> Tom Rini wrote: > >On Thu, Feb 26, 2004 at 03:30:08PM -0800, George Anzinger wrote: > > > >>Amit S. Kale wrote: > >> > >>>On Thursday 26 Feb 2004 3:23 am, Tom Rini wrote: > >>> > >>> > >>>>The following patch fixes a number of little issues here and there, and > >>>>ends up making things more robust. > >>>>- We don't need kgdb_might_be_resumed or kgdb_killed_or_detached. > >>>>GDB attaching is GDB attaching, we haven't preserved any of the > >>>>previous context anyhow. > >>> > >>> > >>>If gdb is restarted, kgdb has to remove all breakpoints. Present kgdb > >>>does that in the code this patch removes: > >>> > >>>- if (remcom_in_buffer[0] == 'H' && remcom_in_buffer[1] == > >>>'c') { > >>>- remove_all_break(); > >>>- atomic_set(&kgdb_killed_or_detached, 0); > >>>- ok_packet(remcom_out_buffer); > >>> > >>>If we don't remove breakpoints, they stay in kgdb without gdb not > >>>knowing it and causes consistency problems. > >> > >>I wonder if this is worth the trouble. Does kgdb need to know about > >>breakpoints at all? Is there some other reason it needs to track them? > > > > > >I don't know if it's strictly needed, but it's not the hard part of this > >particular issue (as I suggested in another thread, remove_all_break() > >on a ? packet works). > > > > > >>>>- Don't try and look for a connection in put_packet, after we've tried > >>>>to put a packet. Instead, when we receive a packet, GDB has > >>>>connected. > >>> > >>> > >>>We have to check for gdb connection in putpacket or else following > >>>problem occurs. > >>> > >>>1. kgdb console messages are to be put. > >>>2. gdb dies > >>>3. putpacket writes the packet and waits for a '+' > >> > >>Oops! Tom, this '+' will be sent under interrupt and while kgdb is not > >>connected. Looks like it needs to be passed through without causing a > >>breakpoint. Possible salvation if we disable interrupts while waiting > >>for the '+' but I don't think that is a good idea. > > > > > >I don't think this is that hard of a problem anymore. I haven't enabled > >console messages, but I've got the following being happy now: > console pass through is the hard one as it is done outside of kgdb under > interrupt control. Thus the '+' will come to the interrupt handler. > > There is a bit of a problem here WRT hiting a breakpoint while waiting for > this '+'. Should only happen on SMP systems, but still....
Here's why I don't think it's a problem (I'll post the new patch shortly, getting from quilt to a patch against previous is still a pain). What happens is: 1. kgdb console tried to send a packet. 2. before ACK'ing the above, gdb dies. 3. kgdb loops on sending a packet and reading in a char. 4. gdb tries to reconnect and sends $somePacket#cs 5. put_packet sends out the console message again, and reads in a char. 6. put_packet sees a $ (or in the case of your .gdbinit, ^C$, which is still fine). 7. put_packet sees a packet coming in, which preempts sending this packet, and will call kgdb_schedule_breakpoint() and then return, giving up on the console message. 8. do_IRQ() calls kgdb_process_breakpoint(), which calls breakpoint() and gdb gets back in the game.
> >- 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?
The 'continue' command in gdb.
> 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.
Hmm. I think I need to test things a bit more, before I comment on this.
-- Tom Rini http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |