Messages in this thread | | | From | "Amit S. Kale" <> | Subject | Re: [Kgdb-bugreport] [PATCH][3/3] Update CVS KGDB's wrt connect / detach | Date | Mon, 1 Mar 2004 15:48:15 +0530 |
| |
On Saturday 28 Feb 2004 4:20 am, Tom Rini wrote: > 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.
You may not have seen the race. I too believe that the race pointed out by George exists.
-Amit
- 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/
| |