Re: [RFC] Add windows Thread Information Block

[Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>]

On Fri, Jun 26, 2009 at 11:52:54AM -0400, Daniel Jacobowitz wrote:
>On Fri, Jun 26, 2009 at 01:47:31AM +0200, Pierre Muller wrote:
>>  - Current limits of stack
>>   The last could be particularly interesting when we try to
>>  to figure out an optimized stack frame.
>>  
>>   When we hit a frameless function without debug information,
>> we could try to find up the stack a valid pair of stored (EBP,EIP)
>> of the outer frame having a frame pointer.
>>   Testing for EBP to bee within the limits given by 
>>   current_top_of_stack andcurrent_bottom_of_stack
>> would help to find correct pairs.
>
>Does Windows allow separate stacks, a la sigaltstack?  Or is the stack
>always guaranteed to be within this range?

I don't think so.

>>But here I need advice on how to move the display_tib function to
>>windows-tdep.c file, as it is currently using internal information of
>>windows-nat.c thread_info struct.  Also how should I handle the remote
>>case?  Should I add a new query, something like 'qTlb'?  How should I
>>call this from windows-tdep code?
>
>You'd probably want a new 'target object' for this, and a qXfer packet
>to read it.  Take a look at "info auxv", which is very similar.
>
>You might also want to consider treating this like $_siginfo.  It's
>fine to also have an info command to display it, but I bet folks'll
>want to examine memory at some of these addresses or write scripts
>using them, so having it as a normal "struct value" would help.
>_siginfo is implemented using a target object, too.

Good suggestion.  That's exactly what I'd like to use it for.  There is
a field in the TIB which allows you to access the memory without going
through the fs register but that's an added level of typing which it
would be nice to avoid.

cgf