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 redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 17 Sep 2003 12:23:21 -0400
- Subject: Re: RFC: Two small remote protocol extensions
- References: <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> <3D93B6E6.8030805@redhat.com> <20030629021605.GA18990@nevyn.them.org> <3F567C28.1040906@redhat.com> <20030917155115.GA7896@nevyn.them.org> <3F688997.4030605@redhat.com>
On Wed, Sep 17, 2003 at 12:19:35PM -0400, Andrew Cagney wrote:
>
> >Well, Ht is effectively a new letter - H is only defined for c and g.
> >We could explicitly state that, or look for a new letter. I recommend
> >a multi-letter sequence, the extra bytes don't matter and we don't have
> >all that many letters.
>
> Definitly a multi-letter sequence, but a new letter :-)
>
> >To summarize, here's what we seem to have now natively:
> > - Single step one thread, all others stopped.
> > - Single step one thread, all others continued.
> > - Signal one thread, all others stopped.
> > - Signal one thread, all others continued.
> > - Continue all threads.
> >
> >Here's what I think would be useful, though:
> > - Per thread, specify stopped/singlestepped/signal/continue.
> >
> >Some of the combinations aren't useful; singlestepping multiple threads
> >for instance is not usually useful. Well, I suppose it could be.
>
> Who are we to argue :-)
Heh.
> >But specific signals to multiple threads at the same time (well, same
> >time is really kind of approximate without better native interfaces...)
> >- now that's useful in debugging race conditions.
> >
> >So, do you agree? If so, here's just one possible way to implement it.
> >I left it as Ht because I'm too lazy to go find another letter. This
> >doesn't include step out of range because I'm not sure how that should
> >look (what was the problem with step out of range anyway? That caused
> >it to get disabled? - and its current syntax is not in the manual).
>
> It wasn't thread friendly, wasn't documented, it wasn't consistent with
> the other continuation packets (it had two replies).
OK. I think there's room to add it to something like this, so I'm not
gonna fret about it for now.
> > Ht 'TID' 'DISPOSITION' [';' 'TID' 'DISPOSITION']... [';' 'DISPOSITION']
> >
> >'TID' should be a numeric thread ID, to affect one thread.
> >
> >'DISPOSITION' can be:
> > 's'
> > 'c'
> > 'C' 'SIGNAL'
>
> I hope TID is decimal :-)
Heh, 'c', right. Any objection to using decimal thread IDs, or would
you rather have 'TID' : 'DISPOSITION' ; ... ?
> >A final 'DISPOSITION' is applied to all threads not explicitly listed.
> >
> >Note that this Ht is a continue packet, not a select-thread packet. So
> >Ht is not a good choice.
>
> Yep.
How about, um, "vCont"?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer