On Wednesday 22 October 2008 19:05:09, Michael Snyder wrote:
> Pedro Alves wrote:
> 
> > Could you try this out please?  It works here against gdbserver
> > single|multi-process, and sends a `T000000tid' (tid alive) packet when
> > multi-process isn't in effect.
> 
> Thanks for working up the patch -- it works for my target.

Thanks for testing.

> 
> However, I must say that I'm not crazy about the idea that
> we decide whether or not to send leading zeroes based on
> whether the target is multi-process.  Seems orthogonal
> and ad hoc.

I can't think of a valid reason why we'd have this
inconsistency:

 --> Hg p1.2
 ...

 --> vCont;s:p1.2
 <-- T05 thread:p1.2

 -->  qfThreadInfo
 <--  m p1.2
 -->  qfThreadInfo
 <--  m p1.3
 ...

 (others)

But:

 --> T p00000001.00000002

?

Especially since we centralized the thread-id definition for multi-process:

 "In addition, the remote protocol supports a multiprocess feature
 in which the thread-id syntax is extended to optionally include both
 process and thread ID fields, as `ppid.tid'. The pid (process) and
 tid (thread) components each have the format described above: a
 positive number with target-specific interpretation formatted as
 a big-endian hex string, literal `-1' to indicate all processes or
 threads (respectively), or `0' to indicate an arbitrary process or
 thread. Specifying just a process, as `ppid', is equivalent to
 `ppid.-1'. It is an error to specify all processes but a specific
 thread, such as `p-1.tid'. Note that the `p' prefix is not used
 for those packets and replies explicitly documented to include a
 process ID, rather than a thread-id. "

... and we nowhere hardcoded 64-bit hex numbers.

Perhaps the previous patch was too invasive for such a simple need.
Since this is only required in the thread alive packet, and since
we already have to special case... would you be happy with the
attached patch?  I know I would.  :-)

-- 
Pedro Alves