Re: bsd-kvm target, always a thread

[Pedro Alves <pedro@codesourcery.com>]

On Sunday 10 August 2008 16:54:52, Mark Kettenis wrote:
> > From: Pedro Alves <pedro@codesourcery.com>

> > > Sure, I'd just think you should use something that's a bit less
> > > arbitrary than 42000 (which could be confused with a real process ID)
> > > here.
> >
> > Eh, 42 carries some history.  :-)  It was used in several targets
> > already, even before I started changing then to use ptid(pid,0,tid), and
> > always registering a thread.  monitor used 42000, remote used 42000,
> > remote-sim used 42, go32-nat.c uses 42.  I just thought that carrying it
> > around would make it easier to spot what it is.
>
> I can see where that 42 is coming from.  So 42000 can defenitely not
> be the answer! ;).

This is used in targets that either have no notion of pids
whatsoever, (monitor, go32-nat, remote-sim fall in this category) or
the protocol/stub doesn't report those (remote-m32c I guess).  remote.c
falls a bit on both sides, and so has a somewhat special handling of
this.  See below.

> Seriously though, the fact the it was changed for 42 to 42000 in some
> places is a hint that there is a problem here.  There must have been a
> collision between 42 and a real process ID somehwre.  And I guess it
> was changed to 42000 since many Unix systems process IDs are 16-bit.
> But there may be modern systems around that use larger values.

See below.

> > Let's not use -1, as that conflicts a bit with the special
> > ptid(-1,0,0) (aka, minus_one_ptid).
>
> Not if you set the lwpid or tid to something non-zero.
>

It does, if you want to use (pid,0,0) to refer to the whole inferior,
vs (-1,0,0) to mean all threads of all inferiors.

> > I actually have a patchlet in my series to bring back the 42000:
> >
> >  remote.c:
> >    /* Take advantage of the fact that the LWP field is not used, to tag
> >       special ptids with it set to != 0.  */
> >  -  magic_null_ptid = ptid_build (0, 1, -1);
> >  -  not_sent_ptid = ptid_build (0, 1, -2);
> >  -  any_thread_ptid = ptid_build (0, 1, 0);
> >  +  magic_null_ptid = ptid_build (42000, 1, -1);
> >  +  not_sent_ptid = ptid_build (42000, 1, -2);
> >  +  any_thread_ptid = ptid_build (42000, 1, 0);
> >
> > I guess we're numerically converging :-)
>
> Well, that diff would be simply wrong!  What if you're debugging
> process ID 42000 remotely?

No, notice that the lwp member is != 0.

There is currently no problem whatsoever in this case.  This id is only
used when the remote side does *not* support or report any pid/thread
id, or is supported, hasn't reported to GDB yet.  It is never passed
back to the remote side, e.g,

  if (ptid_equal (ptid, magic_null_ptid))
    {
      /* MAGIC_NULL_PTID means that we don't have any active threads,
	 so we don't have any TID numbers the inferior will
	 understand.  Make sure to only send forms that do not specify
	 a TID.  */
      if (step && siggnal != TARGET_SIGNAL_0)
	outbuf = xstrprintf ("vCont;S%02x", siggnal);
      else if (step)
	outbuf = xstrprintf ("vCont;s");
      else if (siggnal != TARGET_SIGNAL_0)
	outbuf = xstrprintf ("vCont;C%02x", siggnal);
      else
	outbuf = xstrprintf ("vCont;c");
    }

ptid(42000,1,-1) can never be mistaken with a real pid, since the
lwp member is != 0, and that is never used for a ptid representing a process
or thread id reported by the remote side.

...
Check out remote.c:set_thread:

/* If PTID is MAGIC_NULL_PTID, don't set any thread.  If PTID is
   MINUS_ONE_PTID, set the thread to -1, so the stub returns the
   thread.  If GEN is set, set the general thread, if not, then set
   the step/continue thread.  */

Also remote.c:record_currthread, where we detect that the stub reported
a pid/tid, which means we can stop using magic_null_ptid at that point.

Also see remote.c:remote_start_remote, where we override magic_null_ptid
current thread with reported by qC, if the stub suports it.

(yes, remote.c:extended_remote_create_inferior_1 could be checking
if the remote reported a pid/tid in the stop reply to vRun, and
querying the remote for the current thread with qC, if qC
is supported --- I've come across this when working on the
multi-process remote work)

> I guess this will do for now.

Thanks, I'll go check it in.  Indeed, we can always revisit this when
we need it.  I'm seriously *not* trying to get in your way.  :-)

-- 
Pedro Alves