From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8455 invoked by alias); 6 Dec 2004 23:44:38 -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 8429 invoked from network); 6 Dec 2004 23:44:34 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 6 Dec 2004 23:44:34 -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 iB6NiTBr016908 for ; Mon, 6 Dec 2004 18:44:34 -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 iB6NiNr12350; Mon, 6 Dec 2004 18:44:23 -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 iB6NiNGE003858; Mon, 6 Dec 2004 18:44:23 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id iB6NiHg9015168; Mon, 6 Dec 2004 16:44:18 -0700 Date: Mon, 06 Dec 2004 23:46:00 -0000 From: Kevin Buettner To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Generic support for qGetTLSAddr packet Message-ID: <20041206164416.5eba79c4.kevinb@redhat.com> In-Reply-To: <200412062237.iB6MbIGY000533@elgar.sibelius.xs4all.nl> References: <20041206143109.7e29789f.kevinb@redhat.com> <200412062237.iB6MbIGY000533@elgar.sibelius.xs4all.nl> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00181.txt.bz2 On Mon, 6 Dec 2004 23:37:18 +0100 (CET) Mark Kettenis wrote: > Yikes! That qGetTLSAddr in the function name is really ugly. Yeah, it is. Okay, how about something like get_remote_TLS_load_module_params ? > 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? A thread local address is requested via to_get_thread_local_address(). Here's the comment / declaration from target.h: /* Return the thread-local address at OFFSET in the thread-local storage for the thread PTID and the shared library or executable file given by OBJFILE. If that block of thread-local storage hasn't been allocated yet, this function may return an error. */ CORE_ADDR (*to_get_thread_local_address) (ptid_t ptid, struct objfile *objfile, CORE_ADDR offset); Abstracting this only a little bit, the following pieces of information are needed: 1) The thread id associated with the thread local storage. Native GDB gets this from ``ptid''. 2) The load module containing the thread local storage. Native GDB gets this by examining ``objfile''. 3) The offset provided by the debug information. (Provided by ``offset''.) (1) and (3) are provided to the stub in an unsurprising fashion. (2), the load module, is represented by an objfile which is a struct (pointer) The gdbarch method (whose name you object to) provides a mechanism by which suitable portions of the objfile struct may be extracted / translated for benefit of the stub. As Daniel indicates, for GNU/Linux, the crucial bit of translation needed by the stub is the mapping from objfile to a linkmap address. (This is something that it would be difficult for the stub to do on its own.) However, this link map address is simply another representation of the load module, albeit in a form that's readily usable by the stub. > The patch below implements support for the qGetTLSAddr packet. See: > > http://sources.redhat.com/ml/gdb/2004-11/msg00189.html > > This patch also adds a new gdbarch method for fetching the OS / ABI > specific load module parameters. > > I don't think this should be added to the "glibal" gdbbarch vector. > Instead, this probably should be architecture-dependent data that's > only known to the remote protocol module. Yeah, this could be done. I'll look to see what the implications are of doing it this way... Kevin