Re: RFC: Two small remote protocol extensions

Andrew Cagney
2002-08-23T15:57:38Z

> 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).

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.

enjoy,
Andrew

> 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
>
>>
>>