From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12683 invoked by alias); 10 Mar 2010 22:23:05 -0000 Received: (qmail 12669 invoked by uid 22791); 10 Mar 2010 22:23:03 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.154) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Mar 2010 22:22:59 +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 o2AMMqq0082423 ; Wed, 10 Mar 2010 23:22:52 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) 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 o2AMMqcn095972 ; Wed, 10 Mar 2010 23:22:52 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (lec67-4-82-230-53-140.fbx.proxad.net [82.230.53.140]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o2AMMppD030116 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 10 Mar 2010 23:22:51 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Pedro Alves'" , References: <000901c9f5ef$4ee06f10$eca14d30$@u-strasbg.fr> <20090703194220.GA30668@ednor.casa.cgf.cx> <002901cac075$1f8f44b0$5eadce10$@muller@ics-cnrs.unistra.fr> <201003101725.48298.pedro@codesourcery.com> In-Reply-To: <201003101725.48298.pedro@codesourcery.com> Subject: RE: [PING] [RFC-v3] Add windows Thread Information Block Date: Wed, 10 Mar 2010 22:23:00 -0000 Message-ID: <000c01cac0a0$3935fbe0$aba1f3a0$@muller@ics-cnrs.unistra.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: 2010-03/txt/msg00400.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoy=E9=A0: Wednesday, March 10, 2010 6:26 PM > =C0=A0: gdb-patches@sourceware.org > Cc=A0: Pierre Muller > Objet=A0: Re: [PING] [RFC-v3] Add windows Thread Information Block >=20 > On Wednesday 10 March 2010 17:14:19, Pierre Muller wrote: > > Despite all my efforts, > > I never managed to get advices on the non-windows part of > > this patch :( > > > > I appended at the bottom of this email an > > updated patch. > > To refresh memories, > > this patch enables looking at the 'Thread Local Base' > > an internal Windows structure describing the current thread > > and some process wide features. > > The main problem was about my use of TARGET_OBJECT_OSDATA > > to get this information from the gdbserver, which did not seem > > to be compatible with the general usage of TARGET_OBJECT_OSDATA. > > > > I would really like to get new feedback on that > > issue. >=20 > Sorry, I already explained long ago that TARGET_OBJECT_OSDATA > is being misused here.=20=20 OK, I start to remember now, you said that TARGET_OBJECT_DATA should use xml syntax for=20 all data transmission, what that it? > Why the resistence to change that? It's not resistance, its just that I have no xml knowledge, and I still don't really understand why=20 xml should be required for all TARGET_OBJECT_DATA. =20=20 > There's another bit you haven't addressed yet: >=20 > > + 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) >=20 > As I explained before, for partial xfers you should not > design the protocol relying on `len' being exactly 4 or 8. > Also, this is just transfering a number, why make that > target-endian dependant (see memcpy above) ? My code does assume that there is a unique call that will fetch either 4 bytes (for windows 32 bit inferior) or 8 bytes for (windows 64 bit inferior) in a unique call, which avoids the static struct used in the linux counter part... (I could have added a check that offset is zero). Anyhow, if you insist on using xml, you will need to=20 help me on how to handle and extract the relevant data from the generated xml. =20 Pierre Muller