From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7769 invoked by alias); 8 Dec 2004 00:24:35 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7704 invoked from network); 8 Dec 2004 00:24:22 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Dec 2004 00:24:22 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iB80OM1l005830 for ; Tue, 7 Dec 2004 19:24:22 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iB80OHr06952; Tue, 7 Dec 2004 19:24:17 -0500 Received: from localhost.localdomain (vpn50-35.rdu.redhat.com [172.16.50.35]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id iB80OGqY018384; Tue, 7 Dec 2004 19:24:16 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id iB80OBCs018448; Tue, 7 Dec 2004 17:24:11 -0700 Date: Wed, 08 Dec 2004 00:38:00 -0000 From: Kevin Buettner To: gdb-patches@sources.redhat.com Cc: Daniel Jacobowitz Subject: Re: [RFC] Generic support for qGetTLSAddr packet Message-ID: <20041207172410.36b8e046.kevinb@redhat.com> In-Reply-To: <20041207170050.03bd5a85.kevinb@redhat.com> References: <20041206143109.7e29789f.kevinb@redhat.com> <200412062237.iB6MbIGY000533@elgar.sibelius.xs4all.nl> <20041206230355.GA31381@nevyn.them.org> <20041207170050.03bd5a85.kevinb@redhat.com> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00222.txt.bz2 On Tue, 7 Dec 2004 17:00:50 -0700 Kevin Buettner wrote: > On Mon, 6 Dec 2004 18:03:55 -0500 > Daniel Jacobowitz wrote: > > > On Mon, Dec 06, 2004 at 11:37:18PM +0100, Mark Kettenis wrote: > > > That said, I don't understand why there's any need for the remote code > > > to get so deep into the core GDB code. I don't see the big picture > > > yet, but my initial reaction is that this must be wrong. Why does the > > > remote protocol need to know more than a native GDB? > > > > Because shared libraries are handled by GDB, and not by gdbserver. > > Take a look at thread_db_get_thread_local_address; there's a call > > to svr4_fetch_objfile_link_map in it, which gdbserver can't do > > (unless we were to add ELF header support to it... yuck). > > Yes, this is exactly right. > > > That said, I wonder if this query should be handled uniquely by > > remote.c, or by GNU/Linux specific code using an xfer-partial > > mechanism. I haven't thought about the details yet. > > I've given this some thought since yesterday. > > This approach would define a new enum target_object (maybe > TARGET_OBJECT_TLS_ADDR) and use to_xfer_partial() to handle the > lookup of thread local addresses. The target method > to_get_thread_local_address() would be eliminated entirely. > > As I indicated in my reply to Mark yesterday, we need three > things to fetch a thread-local address. We need a thread id, > an offset (which is supplied by the debug information), and > some representation of the load module. > > The interface for to_xfer_partial is as follows: > > LONGEST (*to_xfer_partial) (struct target_ops *ops, > enum target_object object, const char *annex, > void *readbuf, const void *writebuf, > ULONGEST offset, LONGEST len); > > This interface does not make it easy to pass the three TLS related > parameters noted above. One of them (probably the TLS offset) could > be passed as to_xfer_partial's ``offset'' parameter. The other two > would have to be encoded in some way and passed as ``annex''. Each > implementation of to_xfer_partial() would have to implement some > decoding logic in order make use of the two encoded parameters. > > Using to_xfer_partial() doesn't really solve the remote protocol > problem either. remote.c would still need to detect > TARGET_OBJECT_TLS_ADDR and construct a suitable qPart packet. > > The problem of the stub not having the load module representation > in an easy to use form would still exist too. > > The only advantage that I can think of with this approach is that it > reduces the number of target_ops methods. (And I don't find this to > be all that compelling.) The disadvantage is that it complicates the > encoding and decoding of the parameters necessary for fetching a TLS > address. As noted above, it doesn't help one way or another with > encoding a suitable packet for the remote protocol. In order to avoid > putting an undue burden on the stub, we'd still need much of the > machinery from my current patch proposal. > > So, unless I completely misunderstood what you had in mind, I'm not > in favor of the to_xfer_partial approach. It's just occurred to me that the encoding of thread-id and load-module into annex could also handle any necessary OS/ABI related translations of the load module. This means that that we wouldn't need two separate code paths which both call svr4_fetch_objfile_link_map(). Of course, the load module translation could also be done (assuming an interface change) prior to the call to_get_thread_local_address(). I think this would address both Mark's and Andrew's comments about remote.c doing somewhat more than expected. I'll mull it over some more... Kevin