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: Christopher Faylor <cgf-use-the-mailinglist-please at sourceware dot org>
- To: gdb-patches at sourceware dot org, Pierre Muller <muller at ics dot u-strasbg dot fr>
- Date: Fri, 26 Jun 2009 11:45:12 -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:
>
> On windows operating system
>each thread gets a Thread Information Block
>which contains several interesting informations:
> - Current top of Structured Exception Handlers
> - Thread Variable allocations
> - Process information
> - 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.
>
>I only tried to implement the 32bit version of
>this until now, the 64bit version has a different layout...
>More fields are available, some being version (or simulation layer)
>dependent...
> The current patch adds the code to windows-nat.c
>despite the fact that I added the thread_local_base field
>to both windows-nat.c and gdbserver/win32-low.c.
> To be also usable for a remote gdbserver,
>I would need to move that to windows-tdep.c
>
> 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?
>
> All comments welcomed!
I can't tell you how many times I've wanted something like this. I
always end up standing on my head to get the tib information. I have no
problem with most of the implementation except that I think this should
be a show command not a stand-alone command. And, while "tib" is an
accepted abbreviation for "thread information block", I think it makes
sense (as Eli was implying, I think) that the actual command should be
"show thread-information-block" with "show tib" as a alias.
And, of course, as Eli said, we do need documentation.
Nevertheless, I appreciate your adding this functionality. It will make
debugging Cygwin much easier.
cgf