From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 611 invoked by alias); 26 Jun 2009 15:45:32 -0000 Received: (qmail 597 invoked by uid 22791); 26 Jun 2009 15:45:29 -0000 X-Spam-Check-By: sourceware.org Received: from pool-98-110-183-121.bstnma.fios.verizon.net (HELO cgf.cx) (98.110.183.121) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Jun 2009 15:45:22 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id C848A3B0008; Fri, 26 Jun 2009 11:45:12 -0400 (EDT) Received: by ednor.cgf.cx (Postfix, from userid 201) id B97CC2B388; Fri, 26 Jun 2009 11:45:12 -0400 (EDT) Date: Fri, 26 Jun 2009 15:45:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org, Pierre Muller Subject: Re: [RFC] Add windows Thread Information Block Message-ID: <20090626154512.GG30070@ednor.casa.cgf.cx> References: <000901c9f5ef$4ee06f10$eca14d30$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000901c9f5ef$4ee06f10$eca14d30$@u-strasbg.fr> User-Agent: Mutt/1.5.19 (2009-01-05) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00714.txt.bz2 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