RE: [PING] [RFC-v3] Add windows Thread Information Block

["Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>]

> -----Message d'origine-----
> De?: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pedro Alves
> Envoyé?: Wednesday, March 10, 2010 6:26 PM
> À?: gdb-patches@sourceware.org
> Cc?: Pierre Muller
> Objet?: Re: [PING] [RFC-v3] Add windows Thread Information Block
> 
> On Wednesday 10 March 2010 17:14:19, Pierre Muller wrote:
> > Despite all my efforts,
> > I never managed to get advices on the non-windows part of
> > this patch :(
> >
> >   I appended at the bottom of this email an
> > updated patch.
> >   To refresh memories,
> > this patch enables looking at the 'Thread Local Base'
> > an internal Windows structure describing the current thread
> > and some process wide features.
> >   The main problem was about my use of TARGET_OBJECT_OSDATA
> > to get this information from the gdbserver, which did not seem
> > to be compatible with the general usage of TARGET_OBJECT_OSDATA.
> >
> >   I would really like to get new feedback on that
> > issue.
> 
> Sorry, I already explained long ago that TARGET_OBJECT_OSDATA
> is being misused here.  
  OK, I start to remember now,
you said that TARGET_OBJECT_DATA should use xml syntax for 
all data transmission, what that it?

> Why the resistence to change that?
It's not resistance, its just that I have no xml knowledge,
and I still don't really understand why 
xml should be required for all TARGET_OBJECT_DATA.

  
> There's another bit you haven't addressed yet:
> 
> > +	  if (len == 8)
> > +	    {
> > +	      uint64_t tlb = th->thread_local_base;
> > +	      memcpy ((void *)readbuf, (void *) &tlb, len);
> > +	      return len;
> > +	    }
> > +          else if (len == 4)
> 
> As I explained before, for partial xfers you should not
> design the protocol relying on `len' being exactly 4 or 8.
> Also, this is just transfering a number, why make that
> target-endian dependant (see memcpy above) ?

  My code does assume that there is a unique call that
will fetch either 4 bytes (for windows 32 bit inferior)
or 8 bytes for (windows 64 bit inferior) in a unique call,
which avoids the static struct used in the linux counter part...
(I could have added a check that offset is zero).

  Anyhow, if you insist on using xml, you will need to 
help me on how to handle and extract the relevant data from
the generated xml.
 
Pierre Muller