From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29026 invoked by alias); 1 Jul 2009 15:42:44 -0000 Received: (qmail 29016 invoked by uid 22791); 1 Jul 2009 15:42:42 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Jul 2009 15:42:35 +0000 Received: (qmail 17015 invoked from network); 1 Jul 2009 15:42:33 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Jul 2009 15:42:33 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC-v2] Add windows Thread Information Block Date: Wed, 01 Jul 2009 15:42:00 -0000 User-Agent: KMail/1.9.10 Cc: "Pierre Muller" , "'Daniel Jacobowitz'" References: <000901c9f5ef$4ee06f10$eca14d30$@u-strasbg.fr> <20090626155254.GA15627@caradoc.them.org> <001f01c9fa5a$0e1297f0$2a37c7d0$@u-strasbg.fr> In-Reply-To: <001f01c9fa5a$0e1297f0$2a37c7d0$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907011643.45759.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: 2009-07/txt/msg00011.txt.bz2 On Wednesday 01 July 2009 15:41:44, Pierre Muller wrote: > =A0 I tried to look at the siginfo stuff as > Daniel suggested, but found out finally that > there is already a TARGET_OBJECT_OSDATA type > that can be used for this case. I'm not sure. osdata is meant to be used through the get_osdata interface, which assumes the target returns xml encoded tabular form data. See osdata.c, and the "info os" command (use and implementation). You can try "info os processes" against linux native or gdbserver to see it in action. i386-cygwin-tdep.c (this is used for i386-mingw targets too) is a better place for i386 specific structures. windows-tdep.c should only hold code that is shareable with ARM Windows CE too, or any other Windows arch. arm-wince configurations don't pull in that file yet, but they will soon, so considering this now, just avoids having to move the code later on. Please be aware that with the xfer_partial interfaces, you have to handle requests for fragments of the whole information. This means that while this currently works for you: + if (len =3D=3D 8) + { + uint64_t tlb =3D th->thread_local_base; + memcpy ((void *)readbuf, (void *) &tlb, len); + return len; + } + else if (len =3D=3D 4) + { + uint32_t tlb =3D th->thread_local_base; + memcpy ((void *)readbuf, (void *) &tlb, len); + return len; + } It is not correct. Nothing is preventing GDB from splitting the read in two or more requests, say: bytes [0,3[, then bytes [3, 8[. Take a look at linux-low.c:linux_xfer_siginfo to see this being considered. > Using such a convenience variable would then require that > at each thread switch we reload the variable, > or at least that we tag it as 'invalid' (or is 'lazy' OK or this?) > I have no idea if/how this is possible? The $_siginfo mechanism handles that by making the $_siginfo value be a "computed" value. That is, the value is always re-fetched and "computed" from the target. So if you switch threads, and then print $_siginfo, the data is refetched in the context of the now current thread. It's easier to see it in action. Try placing a breakpoint on siginfo_make_value on an x86-linux box. Finally, this makes me curious: how does this play with TLS (does gcc's __thread support for Windows make use of Windows' standard TLS mechanism's?) ? From the TIB you can fetch the TLS module pointer. It may be something worth considering that when implementing this. http://msdn.microsoft.com/en-us/library/aa908958.aspx lpThreadLocalBase Pointer to a block of data. At offset 0x2C into this block is another pointer, called ThreadLocalSt= oragePointer, that points to an array of per-module thread local storage bl= ocks. This gives a debugger access to per-thread data in the threads of the p= rocess being debugged using the same algorithms that a compiler would use. That is, it seems the effort to implement gdbarch_fetch_tls_load_module_add= ress on top of this fetching of the TLB is a small step.=09 --=20 Pedro Alves