Re: [RFC] Add windows Thread Information Block

Daniel Jacobowitz
2009-06-26T15:53:10Z

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