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

[George Anzinger <george@mvista.com>]

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.

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

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml