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

[Pedro Alves <pedro at codesourcery dot com>]

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.


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.

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.


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



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

-- 
Pedro Alves