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

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

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pedro Alves
> Envoyé : Wednesday, July 01, 2009 5:44 PM
> À : gdb-patches@sourceware.org
> Cc : Pierre Muller; 'Daniel Jacobowitz'
> Objet : Re: [RFC-v2] Add windows Thread Information Block
> 
> On Wednesday 01 July 2009 15:41:44, Pierre Muller wrote:
> 
> >   I tried to look at the siginfo stuff as
> > Daniel suggested, but found out finally that
> > there is already a TARGET_OBJECT_OSDATA type
> > that can be used for this case.
> 
> I'm not sure.  osdata is meant to be used through the get_osdata
> interface,
> which assumes the target returns xml encoded tabular form data.  See
> osdata.c, and the "info os" command (use and implementation).  You
> can try "info os processes" against linux native or gdbserver to
> see it in action.

  I didn't see that :(
   
> i386-cygwin-tdep.c (this is used for i386-mingw targets too)
> is a better place for i386 specific structures.  windows-tdep.c
> should only hold code that is shareable with ARM Windows CE too,
> or any other Windows arch.  arm-wince configurations don't pull
> in that file yet, but they will soon, so considering this now,
> just avoids having to move the code later on.

  The link that you give below doesn't say that this is
only valid for i386... Maybe thread local base is also set for ARM wince?
  Could someone test this out?

> Please be aware that with the xfer_partial interfaces, you have
> to handle requests for fragments of the whole information.  This
> means that while this currently works for you:
> 
> +         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.
 
  This is a pain... So maybe add a new TARGET_OBJECT type is 
easier :( 
> >   Using such a convenience variable would then require that
> > at each thread switch we reload the variable,
> > or at least that we tag it as 'invalid' (or is 'lazy' OK or this?)
> > I have no idea if/how this is possible?
> 
> The $_siginfo mechanism handles that by making the $_siginfo value
> be a "computed" value.  That is, the value is always re-fetched and
> "computed" from the target.  So if you switch threads, and then
> print $_siginfo, the data is refetched in the context of the now
> current thread.  It's easier to see it in action.  Try placing a
> breakpoint on siginfo_make_value on an x86-linux box.
> 

  OK, this would then probably also work for
$_tib... 
  One more question:
  What if we switch from debugging a win32 application to a win64,
will the type of $_tib be also recomputed correctly?

> Finally, this makes me curious: how does this play with TLS (does
> gcc's __thread support for Windows make use of Windows' standard
> TLS mechanism's?) ?  From the TIB you can fetch the TLS module pointer.
  Last time I tried,
thread vars were not implemented for win32 in gcc :(

> It may be something worth considering that when implementing this.
> 
> http://msdn.microsoft.com/en-us/library/aa908958.aspx
> 
>  lpThreadLocalBase
> 
>     Pointer to a block of data.
> 
>     At offset 0x2C into this block is another pointer, called
> ThreadLocalStoragePointer, that points to an array of per-module thread
> local storage blocks.
> 
>     This gives a debugger access to per-thread data in the threads of
> the process being debugged using the same algorithms that a compiler
> would use.
> 
> That is, it seems the effort to implement
> gdbarch_fetch_tls_load_module_address
> on top of this fetching of the TLB is a small step.

  In principle, yes. But the TLS field seems to
remain empty in all the tests I made even though TlsAlloc function
is called..