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

[Tom Rini]

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:
- 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.  For the last one, there's
2 packet instead of ACKs, then a NAK, but I believe this is acceptable.

-- 
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/