From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2536 invoked by alias); 26 Jun 2009 16:11:20 -0000 Received: (qmail 2528 invoked by uid 22791); 26 Jun 2009 16:11:19 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.157) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Jun 2009 16:11:13 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n5QGB73i098744 ; Fri, 26 Jun 2009 18:11:07 +0200 (CEST) Received: from mailserver.u-strasbg.fr (ms3.u-strasbg.fr [IPv6:2001:660:2402:d::12]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id n5QGB7qA048014 ; Fri, 26 Jun 2009 18:11:07 +0200 (CEST) (envelope-from muller@ics.u-strasbg.fr) Received: from d620muller (www-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id n5QGB6Bq078794 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 26 Jun 2009 18:11:06 +0200 (CEST) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "'Daniel Jacobowitz'" Cc: References: <000901c9f5ef$4ee06f10$eca14d30$@u-strasbg.fr> <20090626155254.GA15627@caradoc.them.org> In-Reply-To: <20090626155254.GA15627@caradoc.them.org> Subject: RE: [RFC] Add windows Thread Information Block Date: Fri, 26 Jun 2009 16:11:00 -0000 Message-ID: <000901c9f678$b5946700$20bd3500$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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/msg00728.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Daniel Jacobowitz > Envoy=E9=A0: Friday, June 26, 2009 5:53 PM > =C0=A0: Pierre Muller > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [RFC] Add windows Thread Information Block >=20 > 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. >=20 > Does Windows allow separate stacks, a la sigaltstack? Or is the stack > always guaranteed to be within this range? Each thread has its own stack with limits that are given in these two fields (the lower limit can be extended as needed by the OS). =20 > > 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? >=20 > 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. Is it OK, to add a target method that is only supported by one specific target? =20 > 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. Would you mean something like $_tib to be able to use it in scripts? Sounds like a good idea. Pierre