From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19533 invoked by alias); 8 Dec 2004 00:38:01 -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 19503 invoked from network); 8 Dec 2004 00:37:57 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 8 Dec 2004 00:37:57 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Cbpq9-0007lZ-Eo; Tue, 07 Dec 2004 19:37:57 -0500 Date: Wed, 08 Dec 2004 01:39:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Generic support for qGetTLSAddr packet Message-ID: <20041208003756.GA29715@nevyn.them.org> Mail-Followup-To: Kevin Buettner , gdb-patches@sources.redhat.com References: <20041206143109.7e29789f.kevinb@redhat.com> <200412062237.iB6MbIGY000533@elgar.sibelius.xs4all.nl> <20041206230355.GA31381@nevyn.them.org> <20041207170050.03bd5a85.kevinb@redhat.com> <20041207172410.36b8e046.kevinb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041207172410.36b8e046.kevinb@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-12/txt/msg00223.txt.bz2 On Tue, Dec 07, 2004 at 05:24:10PM -0700, Kevin Buettner wrote: > > So, unless I completely misunderstood what you had in mind, I'm not > > in favor of the to_xfer_partial approach. I thought about it some more also; I think your analysis was right, there's not much to gain here. Except... (see bottom). > 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... Another thing I was thinking about was the usefulness of target-agnostic code for this - I think, very small. We know what the get-tls-address operation looks like for GNU/Linux, but not (at least not I) for any other system. Presumably there's some way to do this on Solaris too. Pending more systems with similar problems, it would be nice if we could organize all the logic into target-specific code. Here's where using target_xfer_partial would be convenient. I visualize something like this: linux-nat.c provides to_xfer_partial, which can provide X linux-tdep.c overrides remote.c's to_xfer_partial (this would require a bit of fiddling - I think the best way would be to steer clear of target inheritance, and use a gdbarch hook called from the remote.c version), with another method for providing X What the arguments to X should look like, I'm not sure. It would be nice to pass the objfile directly, but the to_xfer_partial interface is not friendly to that; it would be logical to pass the link map address, but that breaks the abstraction. Hmm.... -- Daniel Jacobowitz