From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1471 invoked by alias); 1 Jul 2009 16:18:48 -0000 Received: (qmail 1461 invoked by uid 22791); 1 Jul 2009 16:18:47 -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.155) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Jul 2009 16:18:41 +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 n61GIYV5060382 ; Wed, 1 Jul 2009 18:18:34 +0200 (CEST) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402:d::11]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id n61GIYjo020100 ; Wed, 1 Jul 2009 18:18:34 +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 n61GIX8h098296 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 1 Jul 2009 18:18:33 +0200 (CEST) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "'Pedro Alves'" , Cc: "'Daniel Jacobowitz'" References: <000901c9f5ef$4ee06f10$eca14d30$@u-strasbg.fr> <001f01c9fa5a$0e1297f0$2a37c7d0$@u-strasbg.fr> <200907011643.45759.pedro@codesourcery.com> <200907011706.26291.pedro@codesourcery.com> In-Reply-To: <200907011706.26291.pedro@codesourcery.com> Subject: RE: [RFC-v2] Add windows Thread Information Block Date: Wed, 01 Jul 2009 16:18:00 -0000 Message-ID: <002a01c9fa67$9bceda10$d36c8e30$@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-07/txt/msg00019.txt.bz2 > > It is not correct. =A0Nothing is preventing GDB from splitting > > the read in two or more requests, say: > > > > bytes [0,3[, then bytes [3, 8[. =A0Take a look at > > linux-low.c:linux_xfer_siginfo to see this being considered. >=20 > I wrote this without really trying to see what was being > transfered, and just assumed the whole data block was being > transfered, which is what would make sense to me when requesting > a TLB object. I now see that this is transfering the *address* > of the TLB. If just transfering the address of the data is the > way to go, then I'm not certain the xfer_partial interface is > a good fit for this --- we request the tls data pointer with > a "qGetTLSAddr:" packet, and with > target_ops->to_get_thread_local_storage. I would assume a > new target_get_thread_local_block -> "qGetTLBAddr" would > be better. Daniel, what do you think? > If you want to transfer the whole blob, then I'd re-suggest > what Daniel already did: a new target object. There is no need to transfer the whole block as the thread information block is in normal debuggee memory. Once you have the base address of that block, you can simply read it with usual TARGET_OBJECT_MEMORY type target_read. qGetTLBAddr would be OK for me, if others like it. Anyhow, there is no way to change that value (it is the linear base address of the $fs register for i386 and of $gs register for amd64 and changing that is not possible within the API, at least) Furthermore, changing values of the thread information block might also have strange effects! Pierre