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:47:11 +0530 |
| |
On Saturday 28 Feb 2004 3:41 am, 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.
Yes. We need some locking on smp for this purpose.
-Amit
> > -g > > > 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.
- 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/
| |