From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19096 invoked by alias); 1 Jul 2009 16:05:23 -0000 Received: (qmail 18812 invoked by uid 22791); 1 Jul 2009 16:05:21 -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 16:05:15 +0000 Received: (qmail 30350 invoked from network); 1 Jul 2009 16:05:13 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Jul 2009 16:05:13 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC-v2] Add windows Thread Information Block Date: Wed, 01 Jul 2009 16:05:00 -0000 User-Agent: KMail/1.9.10 Cc: "Pierre Muller" , "'Daniel Jacobowitz'" References: <000901c9f5ef$4ee06f10$eca14d30$@u-strasbg.fr> <001f01c9fa5a$0e1297f0$2a37c7d0$@u-strasbg.fr> <200907011643.45759.pedro@codesourcery.com> In-Reply-To: <200907011643.45759.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907011706.26291.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/msg00015.txt.bz2 On Wednesday 01 July 2009 16:43:45, Pedro Alves wrote: > + =A0 =A0 =A0 =A0 if (len =3D=3D 8) > + =A0 =A0 =A0 =A0 =A0 { > + =A0 =A0 =A0 =A0 =A0 =A0 uint64_t tlb =3D th->thread_local_base; > + =A0 =A0 =A0 =A0 =A0 =A0 memcpy ((void *)readbuf, (void *) &tlb, len); > + =A0 =A0 =A0 =A0 =A0 =A0 return len; > + =A0 =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 =A0 =A0else if (len =3D=3D 4) > + =A0 =A0 =A0 =A0 =A0 { > + =A0 =A0 =A0 =A0 =A0 =A0 uint32_t tlb =3D th->thread_local_base; > + =A0 =A0 =A0 =A0 =A0 =A0 memcpy ((void *)readbuf, (void *) &tlb, len); > + =A0 =A0 =A0 =A0 =A0 =A0 return len; > + =A0 =A0 =A0 =A0 =A0 } >=20 > It is not correct. =A0Nothing is preventing GDB from splitting > the read in two or more requests, say: >=20 > bytes [0,3[, then bytes [3, 8[. =A0Take a look at > linux-low.c:linux_xfer_siginfo to see this being considered. 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. --=20 Pedro Alves