This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Two small remote protocol extensions
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at ges dot redhat dot com>, gdb at sources dot redhat dot com
- Date: Wed, 25 Sep 2002 11:52:06 -0400
- Subject: Re: RFC: Two small remote protocol extensions
- References: <20020502022543.GA22594@nevyn.them.org> <20020816143040.GA22041@nevyn.them.org> <3D5D0F62.4010207@ges.redhat.com> <20020816145306.GA24002@nevyn.them.org> <3D65B53D.8050603@ges.redhat.com> <20020823124453.GA12257@nevyn.them.org> <3D6692AE.90601@ges.redhat.com> <20020823201549.GB26809@nevyn.them.org> <3D6C4C4E.4050409@ges.redhat.com> <20020828133445.GA16642@nevyn.them.org>
On Wed, Aug 28, 2002 at 09:34:45AM -0400, Daniel Jacobowitz wrote:
> On Wed, Aug 28, 2002 at 12:06:38AM -0400, Andrew Cagney wrote:
> > What is the absolute minimum needed?
> >
> > - step off breakpoint / thread-hop
> > = using a sched lock single-step
> > = using software single-step breakpoints and a sched lock continue
> > (Note: this is where the existing interface really falls down -- step=0
> > so remote.c won't know to schedule-lock)
> >
> > - continue
> >
> > I think, after that, everything is an efficiency gain. Looking at the list:
> >
> > > step one, stop others
> >
> > Hardware single-step off of breakpoint.
> > TPID, STEP, !OTH
> > HcTID, s
> >
> > > step one, continue others
> >
> > Hardware single-step.
> > TPID, STEP, OTH
> > H???, s
> >
> > > continue one, stop others
> >
> > Schedule lock.
> > Software single-step off breakpoint.
> > TPID, !STEP, !OTH (wiered)
> > HcTID, c
> >
> > > continue one, continue others
> >
> > Software single-step.
> > General resume.
> > TPID, !STEP, OTH
> > Hc0, c
> >
> > > Something like:
> > > resume (ptid, step, run_others, target_signal)
> > > maybe? Does anyone think step_all is useful (I don't)?
> >
> > It is what a simulator might implement.
> >
> > So looking at the remote protocol. There in't a way of specifying TPID,
> > STEP, OTH (your bug).
>
> OK, I suppose that makes sense. It's pretty much where I was to begin
> with: if Hc is non-zero, lock to that thread; if Hc is 0, resume all
> threads, but where do we step? How would you like to see us specify
> this - I used Hs, a new step packet taking a thread argument might work
> too... etc.
>
> There's also the question of whether any other simulators or targets
> handle this, and how they behave; I'm not familiar with them. Do they
> treat "HcTID, s" as single-step-one-thread-only? I guess they probably
> do.
Andrew,
I was reminded today that this bug is still present, and we haven't
come up with a solution for it. Do you have any ideas?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer