Re: [Kgdb-bugreport] [PATCH][3/3] Update CVS KGDB's wrt connect / detach

[Tom Rini <trini@kernel.crashing.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/