From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263012AbUB0Pte (ORCPT ); Fri, 27 Feb 2004 10:49:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263013AbUB0Pte (ORCPT ); Fri, 27 Feb 2004 10:49:34 -0500 Received: from fed1mtao05.cox.net ([68.6.19.126]:59370 "EHLO fed1mtao05.cox.net") by vger.kernel.org with ESMTP id S263012AbUB0PtZ (ORCPT ); Fri, 27 Feb 2004 10:49:25 -0500 Date: Fri, 27 Feb 2004 08:49:20 -0700 From: Tom Rini To: George Anzinger Cc: "Amit S. Kale" , kernel list , Pavel Machek , kgdb-bugreport@lists.sourceforge.net Subject: Re: [Kgdb-bugreport] [PATCH][3/3] Update CVS KGDB's wrt connect / detach Message-ID: <20040227154920.GX1052@smtp.west.cox.net> References: <20040225213626.GF1052@smtp.west.cox.net> <20040225214343.GG1052@smtp.west.cox.net> <20040225215309.GI1052@smtp.west.cox.net> <200402261344.49261.amitkale@emsyssoft.com> <403E8180.1060008@mvista.com> <20040226235915.GV1052@smtp.west.cox.net> <403EA407.1010405@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403EA407.1010405@mvista.com> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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/