From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16672 invoked by alias); 8 Dec 2004 00:02: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 15273 invoked from network); 8 Dec 2004 00:01:01 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Dec 2004 00:01:01 -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 iB800u1d032723 for ; Tue, 7 Dec 2004 19:01:01 -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 iB800ur01657; Tue, 7 Dec 2004 19:00:56 -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 iB800tqY015986; Tue, 7 Dec 2004 19:00:56 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id iB800omX018398; Tue, 7 Dec 2004 17:00:50 -0700 Date: Wed, 08 Dec 2004 00:24:00 -0000 From: Kevin Buettner To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Generic support for qGetTLSAddr packet Message-ID: <20041207170050.03bd5a85.kevinb@redhat.com> In-Reply-To: <20041206230355.GA31381@nevyn.them.org> References: <20041206143109.7e29789f.kevinb@redhat.com> <200412062237.iB6MbIGY000533@elgar.sibelius.xs4all.nl> <20041206230355.GA31381@nevyn.them.org> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00221.txt.bz2 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. Kevin