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

• Previous message: Paul Wagland: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler"
• Maybe in reply to: Amit S. Kale: "Re: [Kgdb-bugreport] [PATCH][3/3] Update CVS KGDB's wrt connect / detach"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: Tom Rini <trini@kernel.crashing.org>, George Anzinger <george@mvista.com>
Date:	Mon, 1 Mar 2004 15:48:15 +0530

On Saturday 28 Feb 2004 4:20 am, Tom Rini wrote:
> 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.

You may not have seen the race. I too believe that the race pointed out by
George exists.

-Amit

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

• Previous message: Paul Wagland: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler"
• Maybe in reply to: Amit S. Kale: "Re: [Kgdb-bugreport] [PATCH][3/3] Update CVS KGDB's wrt connect / detach"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]