Re: [RFA] Restore leading zeros in remote_thread_alive

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 22 October 2008 02:02:19, Michael Snyder wrote:
> --- remote.c    17 Oct 2008 19:43:47 -0000      1.321
> +++ remote.c    22 Oct 2008 01:00:16 -0000
> @@ -1433,15 +1433,15 @@ write_ptid (char *buf, const char *endbu
>      {
>        pid = ptid_get_pid (ptid);
>        if (pid < 0)
> -       buf += xsnprintf (buf, endbuf - buf, "p-%x.", -pid);
> +       buf += xsnprintf (buf, endbuf - buf, "p-%08x.", -pid);
>        else
> -       buf += xsnprintf (buf, endbuf - buf, "p%x.", pid);
> +       buf += xsnprintf (buf, endbuf - buf, "p%08x.", pid);
>      }
>    tid = ptid_get_tid (ptid);
>    if (tid < 0)
> -    buf += xsnprintf (buf, endbuf - buf, "-%x", -tid);
> +    buf += xsnprintf (buf, endbuf - buf, "-%x08", -tid);
>    else
> -    buf += xsnprintf (buf, endbuf - buf, "%x", tid);
> +    buf += xsnprintf (buf, endbuf - buf, "%x08", tid);
>  
>    return 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-000000001
correctly, because they were expecting Hg-1, or e.g., misparsing vCont, because
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.

-- 
Pedro Alves