Re: [RFC-v2] Add windows Thread Information Block

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 01 July 2009 16:43:45, Pedro Alves wrote:
> + ? ? ? ? if (len == 8)
> + ? ? ? ? ? {
> + ? ? ? ? ? ? uint64_t tlb = th->thread_local_base;
> + ? ? ? ? ? ? memcpy ((void *)readbuf, (void *) &tlb, len);
> + ? ? ? ? ? ? return len;
> + ? ? ? ? ? }
> + ? ? ? ? ?else if (len == 4)
> + ? ? ? ? ? {
> + ? ? ? ? ? ? uint32_t tlb = th->thread_local_base;
> + ? ? ? ? ? ? memcpy ((void *)readbuf, (void *) &tlb, len);
> + ? ? ? ? ? ? return len;
> + ? ? ? ? ? }
> 
> It is not correct. ?Nothing is preventing GDB from splitting
> the read in two or more requests, say:
> 
> bytes [0,3[, then bytes [3, 8[. ?Take a look at
> linux-low.c:linux_xfer_siginfo to see this being considered.

I wrote this without really trying to see what was being
transfered, and just assumed the whole data block was being
transfered, which is what would make sense to me when requesting
a TLB object.   I now see that this is transfering the *address*
of the TLB.  If just transfering the address of the data is the
way to go, then I'm not certain the xfer_partial interface is
a good fit for this --- we request the tls data pointer with
a "qGetTLSAddr:" packet, and with
target_ops->to_get_thread_local_storage.  I would assume a
new target_get_thread_local_block -> "qGetTLBAddr" would
be better.  Daniel, what do you think?
If you want to transfer the whole blob, then I'd re-suggest
what Daniel already did: a new target object.

-- 
Pedro Alves