From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25064 invoked by alias); 1 Apr 2010 11:21:46 -0000 Received: (qmail 25043 invoked by uid 22791); 1 Apr 2010 11:21:45 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Apr 2010 11:21:41 +0000 Received: (qmail 13761 invoked from network); 1 Apr 2010 11:21:39 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Apr 2010 11:21:39 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [PING][RFC-v4] Add windows OS Thread Information Block Date: Thu, 01 Apr 2010 11:21:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; ) Cc: "Pierre Muller" References: <000901c9f5ef$4ee06f10$eca14d30$@u-strasbg.fr> <000e01cac488$27dcf970$7796ec50$@muller@ics-cnrs.unistra.fr> <001201cad17f$6a058980$3e109c80$@muller@ics-cnrs.unistra.fr> In-Reply-To: <001201cad17f$6a058980$3e109c80$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004011221.36972.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2010-04/txt/msg00005.txt.bz2 On Thursday 01 April 2010 10:40:50, Pierre Muller wrote: > I am still waiting for a comment from any global > maintainer concerning the non-(windows specific) parts > of that patch. Christopher approved the windows part. It is my intention to look at it. It's taking me a bit because it's biggish. On a quick look (not a formal review) I saw: - what looked like some mixed over returning the TIB or the TLB. E.g.: > +/* Write Windows OS Thread Information Block address. */ > +static int > +win32_get_tib_address (ptid_t ptid, CORE_ADDR *addr) ^^^ > +{ > + win32_thread_info *th; > + th = thread_rec (ptid, 0); > + if (th == NULL) > + return 0; > + if (addr) > + *addr = (CORE_ADDR) th->thread_local_base; > + if (th->thread_local_base) ^^^^^^^^^^^^^^^^^^^^^ > + return 1; Does the new packet return the TIB, or the TLB? The object is $_tlb now, isn't it? > > +tlb_value_read (struct value *val) > > +{ ... > > + if (!target_get_tib_address (inferior_ptid, &tlb)) > > + error (_("Unable to read tlb")); Either this is quite confused, or I am. - Assumptions that GDB thread ids are always the same as Win32 threads ids. > > +/* Display thread information block of a thread specified by ARGS. > > + If ARGS is empty, display thread information block of > > current_thread > > + if current_thread is non NULL. > > + Otherwise ARGS is parsed and converted to a integer that should > > + be the windows ThreadID (not the internal GDB thread ID). */ > > +static void > > +display_tib (char * args, int from_tty) > > +{ > > + if (args) > > + { > > + ULONGEST id = (ULONGEST) parse_and_eval_long (args); > > + display_one_tib (ptid_build (ptid_get_pid (inferior_ptid), 0, > > id)); > > + if (target_get_tib_address (ptid, &thread_local_base) == 0) > > + { > > + printf_filtered ("Unable to get thread local base for ThreadId > > %s\n", > > + pulongest (ptid_get_tid(ptid))); > > + return -1; There's no garantee the TID field of ptid matches a windows thread id , particularly when remote debugging (read: that it will always be that way). Do you really need to make this bypass the internal GDB thread id? It would avoid pain if this always worked with the GDB thread id instead. -- Pedro Alves