From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22027 invoked by alias); 11 Mar 2010 00:00:40 -0000 Received: (qmail 22017 invoked by uid 22791); 11 Mar 2010 00:00:39 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 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, 11 Mar 2010 00:00:35 +0000 Received: (qmail 10673 invoked from network); 11 Mar 2010 00:00:33 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Mar 2010 00:00:33 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [PING] [RFC-v3] Add windows Thread Information Block Date: Thu, 11 Mar 2010 00:00:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic; KDE/4.3.2; x86_64; ; ) Cc: "Pierre Muller" References: <000901c9f5ef$4ee06f10$eca14d30$@u-strasbg.fr> <201003101725.48298.pedro@codesourcery.com> <000c01cac0a0$3935fbe0$aba1f3a0$@muller@ics-cnrs.unistra.fr> In-Reply-To: <000c01cac0a0$3935fbe0$aba1f3a0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003110000.31184.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-03/txt/msg00404.txt.bz2 On Wednesday 10 March 2010 22:22:51, Pierre Muller wrote: > > Sorry, I already explained long ago that TARGET_OBJECT_OSDATA > > is being misused here. > OK, I start to remember now, > you said that TARGET_OBJECT_DATA should use xml syntax for > all data transmission, what that it? Basically repeating from : TARGET_OBJECT_OSDATA is meant be used through the get_osdata interface, which assumes the target returns xml encoded tabular form data. See gdb/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. The basic idea of this object, is to be able to fetch tables of operating system related data, like the list of running processes, or the list of running threads, which are the present uses. > > 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 > xml should be required for all TARGET_OBJECT_DATA. See above. > > There's another bit you haven't addressed yet: > > > > > + if (len == 8) > > > + { > > > + uint64_t tlb = th->thread_local_base; > > > + memcpy ((void *)readbuf, (void *) &tlb, len); > > > + return len; > > > + } > > > + else if (len == 4) > > > > 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 > help me on how to handle and extract the relevant data from > the generated xml. I never insisted you used xml... I do insist however, that everything that goes through TARGET_OBJECT_OSDATA respects the get_osdata interface, and that, is tabular/xml based transfer of data. Basically repeating from: : So, if you want to use the qxfer interface, please add a new target object. One note: I think target object's spirit is to transfer the whole data block, which is what would make sense to me when requesting a TLB _object_. The reason that makes me consider transfering the whole blob instead of an address and then relying on plain memory reads issued from GDB, is that on other targets that may want to reuse the interface, the TLB-like object may not be mapped or accessible on the address space accessible with plain memory reads. This is exactly the rationale behind objects like TARGET_OBJECT_AUXV, TARGET_OBJECT_WCOOKIE or TARGET_OBJECT_SIGNAL_INFO: each of these objects can be seen as a blob of data in its own address space. If just transfering the address of the data is the way to go, as you're doing presently, then I'm not certain the xfer_partial interface is a good fit for this --- for example, a simple packet like we use to fetch the tls data pointer seems like a better fit. For example, a new target_get_thread_local_block target method, and a new "qGetTLBAddr:XXX" packet: see the "qGetTLSAddr:" packet for inspiration. I don't have a strong preference which of the directions above should be followed, but, mind you, but, as I said before, TARGET_OBJECT_OSDATA isn't the right interface for this. -- Pedro Alves