This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Add windows Thread Information Block
- From: Daniel Jacobowitz <drow at false dot org>
- To: Pierre Muller <muller at ics dot u-strasbg dot fr>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 26 Jun 2009 11:52:54 -0400
- Subject: Re: [RFC] Add windows Thread Information Block
- References: <000901c9f5ef$4ee06f10$eca14d30$@u-strasbg.fr>
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