Re: [RFC] Add windows Thread Information Block

[Daniel Jacobowitz <drow@false.org>]

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?

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

-- 
Daniel Jacobowitz
CodeSourcery