Re: RFC: Two small remote protocol extensions

[Quality Quorum <qqi at theworld dot com>]

On Fri, 23 Aug 2002, Andrew Cagney wrote:

> > On Thu, 22 Aug 2002, Andrew Cagney wrote:
> >
> >
> >> Lets get rid of the easy one (...) `Hg':
> >>
> >> ``
> >>
> >> @item @code{Hg}@var{id} --- set general thread
> >> @cindex @code{Hc} packet
> >>
> >> Select the general thread.  Register and memory read and write
> >> operations apply to the most recently selected general thread.
>
>
> > ????? Memory is shared between threads, isn't it so ????
>
> The above reflects GDB's current behavour (logical or not).

This is yet another long overdue problem (I had hope it was fixed in
recent releases) -  gdb lumps together mult-process
debugging with multi-tread debugging and it it does not
excell in any of them.

It seems to me that we have to handle multi-process debugging a-la
vxWorks with a separate gdb instance per process and thus forget about it.

>
> When reading or writing memory, gdb specifies a thread.  If it turns out
> that the thread disappeared, GDB picks a thread, any thread (the
> assumption being that all address spaces are pretty much similar).
>
> Mind you, I've seen thread implementations that implemented per-thread
> local data using VM.

It does not mean that everybody else should suffer, it is time to fix
this youthful indiscretion.

>
> enjoy,
> Andrew

Thanks,

Aleksey

>
>
> > IMHO, a multi-process debugging is a very different animal from a
> > multi-thread debugging and lumping them together only creates more
> > problems.
> >
> > Thanks,
> >
> > Aleksey
> >
> >
> >
> >
> >> @var{id}, a hex encoded cardinal, is the identifier of the selected thread.
> >>
> >> After a target stop, the general thread is reset to the thread
> >> identifier of the stopped thread.
> >>
> >> @emph{Implementation note:  The @code{Hg} packet can not be used to
> >> determine the most recently selected thread (using the @samp{thread
> >> @var{thread-id} command).  This is because @value{GDBN} can cache
> >> per-thread data and avoid the need to re-query the target on each
> >> @samp{thread} command.}
> >>
> >> @c Note the word ``can'' is used, not ``does'' :-)
> >>
> >> Reply:
> >> @table @samp
> >> @item OK
> >> for success
> >> @item E00
> >> unspecified error
> >> @c ESRCH --- no such proces/thread?
> >> @item @samp{}
> >> unsupported
> >> @end table
> >>
> >> ''
> >>
> >> Andrew
> >>
> >>
> >
> >> > On Fri, Aug 16, 2002 at 10:42:42AM -0400, Andrew Cagney wrote:
> >> >
> >
> >> >> >On Wed, May 01, 2002 at 10:25:43PM -0400, Daniel Jacobowitz wrote:
> >> >> >
> >
> >> >
> >
> >> >> >>In making remote thread debugging work on GNU/Linux, I needed two
> >> >> >>additions
> >> >> >>to the remote protocol.  Neither is strictly necessary, but both are
> >> >> >>useful,
> >> >> >>IMHO.
> >> >> >>
> >> >> >>They are:
> >> >> >>
> >> >> >>  - two new replies to the continue/step packets, 'n' and 'x'.  They
> >> >> >>indicate thread creation and death respectively, and are asynchronous;
> >> >> >>the target is not stopped when they are sent.
> >
> >> >
> >
> >> >> >
> >> >> >
> >> >> >This one got shouted down, I'm not going to bring it up again.
> >> >> >
> >> >> >
> >
> >> >
> >
> >> >> >>  - A new 'Hs' packet, paralleling Hc and Hg.  This sets the "step"
> >> >> >>  thread.
> >
> >> >
> >
> >> >>
> >> >> How is ``Hs'' different to:
> >> >>
> >> >> 	Hc<PID>
> >> >> 	s
> >
> >> >
> >> >
> >> > Hc<PID> has a definite meaning right now.  It means, step ONLY this
> >> > thread.  That corresponds to set scheduler-locking (on|step).  Hc0 will
> >> > be sent if we are not using scheduler locking.
> >> >
> >> > I see nothing wrong with the current meaning of Hc.
> >> >
> >> > Also, Hs was never meant to INCLUDE the step command.  It sets a thread
> >> > context, that's all.
> >> >
> >> >
> >
> >> >> >This one, however, needs feedback.  A user just reported a bogus
> >> >> >SIGTRAP bug to me which is fixed by the above.
> >> >> >
> >> >> >To elaborate on the problem: right now we have two ways of specifying a
> >> >> >thread to the remote agent.  Hg specifies the "general" thread, and Hc
> >> >> >specifies the "continue" thread.  These correspond to inferior_ptid and
> >> >> >resume_ptid, roughly.
> >> >> >
> >> >> >When we single-step, if we are not using some form of
> >> >> >scheduler-locking, resume_ptid is 0.  We don't tell the agent at that
> >> >> >point what inferior_ptid is; it has to step _some_ thread, and it picks
> >> >> >one, and if it doesn't pick the one GDB expected we get problems.
> >
> >> >
> >
> >> >>
> >> >> Shouldn't it pick the current-thread.
> >
> >> >
> >> >
> >> > As above.
> >> >
> >> >
> >
> >> >> >We need to either:
> >> >> >  - Communicate inferior_ptid via Hg at this time
> >> >> >  - Communicate inferior_ptid via a new Hs explicitly
> >> >> >
> >> >> >I think the former makes sense.  Here's a patch; what do you think of
> >> >> >it?  Also included is the patch for gdbserver; I'd send a separate
> >> >> >patch along afterwards to remove the vestiges of Hs from my testing,
> >> >> >which escaped in the original threads patch.
> >
> >> >
> >
> >> >>
> >> >> No.  general thread is really ``selected thread'' the thread for which
> >> >> the [gG][pP] packets apply.  It is not involved in thread scheduling.
> >
> >> >
> >> >
> >> > We need two thread markers to step correctly; I think using this one is
> >> > more logical.  If you prefer then the code in gdbserver to use Hs is
> >> > already there.
> >> >
> >> >
> >
> >> >> Separate to this is the user interface issue of, if you select a
> >> >> different thread, and then do a step, things get real confused (I think
> >> >> GDB tries to step the current (or stop) thread).
> >
> >> >
> >> >
> >> > No, actually, gdbserver is what gets confused.  You've said this
> >> > several times, and the last time you said it I went to check.  In all
> >> > my tests, both local (lin-lwp) and remote (with Hs patch), everything
> >> > stepped the selected thread gracefully.  This already works.  Even
> >> > scheduler locking works.
> >> >
> >> > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
> >
> >>
> >>
>
>