From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26878 invoked by alias); 10 Aug 2008 17:34:11 -0000 Received: (qmail 26868 invoked by uid 22791); 10 Aug 2008 17:34:10 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 10 Aug 2008 17:33:22 +0000 Received: (qmail 10862 invoked from network); 10 Aug 2008 17:33:20 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Aug 2008 17:33:20 -0000 From: Pedro Alves To: Mark Kettenis Subject: Re: bsd-kvm target, always a thread Date: Sun, 10 Aug 2008 17:34:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org References: <200808080420.05897.pedro@codesourcery.com> <200808091529.08896.pedro@codesourcery.com> <200808101554.m7AFsqwE027830@brahms.sibelius.xs4all.nl> In-Reply-To: <200808101554.m7AFsqwE027830@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808101833.21607.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00278.txt.bz2 On Sunday 10 August 2008 16:54:52, Mark Kettenis wrote: > > From: Pedro Alves > > > 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