Re: remote nits

[Quality Quorum <qqi at world dot std dot com>]

On 13 Dec 1999, J.T. Conklin wrote:

> >>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
> Quality> It seems to me that only one way should survive and others
> Quality> should die. My list of preferences is (1) 32-bit integer,
> Quality> (2) 8-byte thread ref, (3) 16-bit unsigned integer. (*)
> 
> One common way to represent threads is using the address of the thread
> control block --- on a machine with 64 bit addressing, a 64 bit thread
> identifier would be used.  I'd rather use that address than attempt to
> map it into a smaller field.
> 
> Perhaps GDB could use an abstract thread representation rather than
> requiring targets use any particular thread representation.  Perhaps 
> a variable length 'cookie' -- an 8-bit length field followed by that
> many bytes of info.
> 
> I seem to remember that NFSv2's 32 byte file handle was changed to a
> variable length string in NFSv3.

1. I was mistaken there are 4 ways to represent thread: 16-bit 
   integer is used by 'qC' and 8-bit integer is used by 'TXX'.

2. Yes, there are at least 5 ways to solve this problem (invent
   something new or use one of 4 exiting ones). The question was
   which one is more appropriate ? 


I would go with following set of rules: (1)thread id is an unsigned 
64-bit integer represented on the wire in %x format (leading zeros
are omitted) in all transactions except 'qP', 'qQ', 'qL' and 'qM'
which use %08x representation; (2) requests 'Hc-xxxxxx' and 'Hg-xxxxx'
should be interpreted as 'all threads' regardless of the length and 
the pattern of 'xxxxxx', (3) 'TXX' is depreciated. It seems reasonable 
to reserve thread_id 0xffffffffffffffff for internal use, so developers
will be able to use the value internally to pass 'all threads' value
between various parts of there stuff.

In may view it will not break any existing code on the stub side.
The only problem will be that newly developed 64-bit stubs 
working with memories above 4GB (which can use big thread_ids) will not
work with old gdbs, but it was going to be the case anyway (there are
quite few non 64-bit transparent places in existing gdb).

>         --jtc

Thanks,

Aleksey