This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: bsd-kvm target, always a thread
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