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

From: Tom Rini
Date: Thu Feb 26 2004 - 13:12:55 EST


On Thu, Feb 26, 2004 at 01:44:49PM +0530, 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:

OK. After talking with Daniel Jacobowitz abit about this, the '?'
packet will only be sent once per session. So this is how we have to
deal with disconnect / gdb dying. I'll re-work the patch a bit to
reflect this.

> > - 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 '+'
> 4. new gdb sends a protocol initialization packet
> 5. putpacket reads characters in that packet hoping for an incoming '+'
> sending out console message packet on each incoming character
> 6. gdb receives and rejects each console message packet

How about something like the following:
putpacket(msg)
{
if (!kgdb_connected)
return; /* No one wants this */

do {
/* Write out $pack#checksum */
ch = kgdb_get_debug_char();
if (ch == '+' /* ACK */ || ch == '$' /* Packet before an ACK?
must be a reattach. */ )
return;
}
}

With the suggested change for the ? packet, we quickly get to the point
where we're back in kgdb_handle_exception() and will know this is a
restart shortly.

--
Tom Rini
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/