This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Error running remote gdb
- From: Michael Snyder <Michael dot Snyder at palmsource dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: "Bizhan Gholikhamseh (bgholikh)" <bgholikh at cisco dot com>, gdb at sourceware dot org
- Date: Thu, 31 Aug 2006 20:13:19 -0700
- Subject: Re: Error running remote gdb
- References: <F795765B112E7344AF36AA911279641502D19B36@xmb-sjc-212.amer.cisco.com> <1157064448.4466.45.camel@localhost.localdomain> <20060831232835.GA21472@nevyn.them.org>
On Thu, 2006-08-31 at 19:28 -0400, Daniel Jacobowitz wrote:
> On Thu, Aug 31, 2006 at 03:47:28PM -0700, Michael Snyder wrote:
> > This is the first breakpoint that gdb set, above.
> > I'm pretty sure now that it's the thread event breakpoint.
>
> More likely it's the shared library event breakpoint; we don't set the
> thread breakpoints until after we've got a load event for libpthread.
Right.
> > > Packet received: T0501:7ffffd30;40:10000560;thread:6098;
> > > [Switching to thread 24728]
>
> > > Sending packet: $m3000ce98,4#c9...Ack
> > > Packet received: 9421fff0
> > > Sending packet: $M3000ce98,4:7d821008#b1...Ack
> > > Packet received: OK
> > > Sending packet: $m10000560,4#59...Ack
> > > Packet received: 48000181
> > > Sending packet: $M10000560,4:7d821008#41...Ack
> > > Packet received: OK
> > > Sending packet: $vCont;s:6098;c#67...Ack
> >
> > Finally, gdb restores the breakpoints and tells the target
> > to continue.
> >
> > > Packet received: T0501:7ffffd30;40:10000560;thread:6098;
> >
> > Whereupon we immediately hit the breakpoint at main.
> > This is where we went wrong. This shouldn't have happened.
>
> Actually, this looks fine. But we're at 0x10000560; why are we
> reinserting the breakpoint _at this address_ and then continuing?
> Normally you leave the breakpoint out to step over it.
Yeah, that's what I meant. Assuming nothing's wrong with gdb,
it should know that it has to step past the breakpoint before
inserting it -- unles that's part of the semantics of vCont,
which is the part I didn't know.
> I can't think what could cause that.
>
> > This is where I have to admit that I don't know the exact
> > semantics of the vCont message. Over to you, Daniel?
>
> That's a "step only thread 6098, continue all other threads"
> packet, in other words, it corresponds to a single step
> other than over a breakpoint. If we're stepping over a breakpoint we'd
> have not had the trailing ;c.
>