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

["Pierre Muller" <muller@ics.u-strasbg.fr>]

> > 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.

  There is no need to transfer the whole block
as the thread information block is in normal debuggee memory.
Once you have the base address of that block, you can simply read it
with usual TARGET_OBJECT_MEMORY type target_read.

  qGetTLBAddr would be OK for me,
if others like it. Anyhow, there is no way to change that value
(it is the linear base address of the $fs register for i386 and of $gs
register for amd64
and changing that is not possible within the API, at least)

  Furthermore, changing values of the thread information block
might also have strange effects!

Pierre