From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19305 invoked by alias); 22 Oct 2008 13:19:00 -0000 Received: (qmail 19296 invoked by uid 22791); 22 Oct 2008 13:18:59 -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; Wed, 22 Oct 2008 13:18:20 +0000 Received: (qmail 10715 invoked from network); 22 Oct 2008 13:18:18 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Oct 2008 13:18:18 -0000 From: Pedro Alves To: Michael Snyder Subject: Re: [RFA] Restore leading zeros in remote_thread_alive Date: Wed, 22 Oct 2008 13:19:00 -0000 User-Agent: KMail/1.9.9 Cc: "gdb-patches@sourceware.org" References: <48FE7B9B.3040905@vmware.com> In-Reply-To: <48FE7B9B.3040905@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200810221418.22409.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-10/txt/msg00538.txt.bz2 On Wednesday 22 October 2008 02:02:19, Michael Snyder wrote: > --- remote.c=C2=A0=C2=A0=C2=A0=C2=A017 Oct 2008 19:43:47 -0000=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A01.321 > +++ remote.c=C2=A0=C2=A0=C2=A0=C2=A022 Oct 2008 01:00:16 -0000 > @@ -1433,15 +1433,15 @@ write_ptid (char *buf, const char *endbu > =C2=A0 =C2=A0 =C2=A0{ > =C2=A0 =C2=A0 =C2=A0 =C2=A0pid =3D ptid_get_pid (ptid); > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (pid < 0) > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0buf +=3D xsnprintf (buf, endbu= f - buf, "p-%x.", -pid); > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0buf +=3D xsnprintf (buf, endbu= f - buf, "p-%08x.", -pid); > =C2=A0 =C2=A0 =C2=A0 =C2=A0else > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0buf +=3D xsnprintf (buf, endbu= f - buf, "p%x.", pid); > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0buf +=3D xsnprintf (buf, endbu= f - buf, "p%08x.", pid); > =C2=A0 =C2=A0 =C2=A0} > =C2=A0 =C2=A0tid =3D ptid_get_tid (ptid); > =C2=A0 =C2=A0if (tid < 0) > - =C2=A0 =C2=A0buf +=3D xsnprintf (buf, endbuf - buf, "-%x", -tid); > + =C2=A0 =C2=A0buf +=3D xsnprintf (buf, endbuf - buf, "-%x08", -tid); > =C2=A0 =C2=A0else > - =C2=A0 =C2=A0buf +=3D xsnprintf (buf, endbuf - buf, "%x", tid); > + =C2=A0 =C2=A0buf +=3D xsnprintf (buf, endbuf - buf, "%x08", tid); > =C2=A0 > =C2=A0 =C2=A0return buf; ( Now that I've slept a bit, :-) ) I've gone through an old version of the = code and documentation looking for places we use write_ptid now that used to output %08x vs places we used to output "-1" or %x. Indeed, I can only see that in remote_thread_alive. The change above can possibly lead to other stubs out there (with similar assumptions to yours) not parsing e.g., Hg-00= 0000001 correctly, because they were expecting Hg-1, or e.g., misparsing vCont, bec= ause used to be "vCont;c:%x". Also, we don't really need to use %08 when multi-= process is in effect. There should be no multi-process stubs around that depend on leading 0's. I guess this means we get to add a new parameter to write_ptid (leading_zeros ?), and pass 1 where needed... Give me a sec to cook something up. --=20 Pedro Alves