From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263192AbUB0Wx0 (ORCPT ); Fri, 27 Feb 2004 17:53:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263191AbUB0Wwr (ORCPT ); Fri, 27 Feb 2004 17:52:47 -0500 Received: from fed1mtao03.cox.net ([68.6.19.242]:27810 "EHLO fed1mtao03.cox.net") by vger.kernel.org with ESMTP id S263180AbUB0Wu2 (ORCPT ); Fri, 27 Feb 2004 17:50:28 -0500 Date: Fri, 27 Feb 2004 15:50:27 -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: <20040227225026.GL1052@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> <20040227154920.GX1052@smtp.west.cox.net> <403FC0AA.6040205@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403FC0AA.6040205@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 Fri, Feb 27, 2004 at 02:11:54PM -0800, George Anzinger wrote: > Tom Rini wrote: > >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. > > What I am describing does not have anything to do with gdb going away. It > is that in "normal" operation the console output is done with the > interrupts on (i.e. we are not in kgdb as a result of a breakpoint, but > only to do console output). This means that the interrupt that is > generated by the '+' from gdb may well happen and the kgdb interrupt > handler will see the '+' and, with the interrupt handler changes, generate > a breakpoint. All we really want to do is to pass the '+' through to > putpacket. In a UP machine, I think the wait for the '+' is done with the > interrupt system off, however, in an SMP machine, other cpus may see it and > interrupt... At the very least, the interrupt code needs to be able to > determine that no character came in and ignore the interrupt. Today might not be a "smart day" for me, so perhaps I'm just not doing what's need to trigger this, or I'm misreading (but if you can trigger it, w/ Amit's patches in CVS and my 1/2 from yesterday and then my 7 from today, I'd be grateful) but UP and SMP on a UP box both have KGDB_CONSOLE behaving correctly. -- Tom Rini http://gate.crashing.org/~trini/