lkml.org 
[lkml]   [2004]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [Kgdb-bugreport] [PATCH][3/3] Update CVS KGDB's wrt connect / detach
    Date
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:3.495 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site