From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13275 invoked by alias); 17 Feb 2005 20:09:48 -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 13102 invoked from network); 17 Feb 2005 20:09:39 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 17 Feb 2005 20:09:39 -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 j1HK9Y6m001325 for ; Thu, 17 Feb 2005 15:09:39 -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 j1HK9XO01073; Thu, 17 Feb 2005 15:09:34 -0500 Received: from localhost.localdomain (vpnuser34.stuttgart.redhat.com [172.16.4.34]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j1HK9U78027799; Thu, 17 Feb 2005 15:09:32 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with ESMTP id j1HK9O2R023963; Thu, 17 Feb 2005 13:09:24 -0700 Date: Fri, 18 Feb 2005 02:32:00 -0000 From: Kevin Buettner To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, "Levchenko, Vasily V" Subject: Re: Relative and absolute paths in link_map Message-ID: <20050217130923.215ae9af@ironwood.lan> In-Reply-To: <20050217174326.GA18733@nevyn.them.org> References: <9F0F5F4271FA9140BE3E05452E3BDAFE7F3070@mssmsx403.ccr.corp.intel.com> <20050217091415.1f48a6c1@ironwood.lan> <20050217174326.GA18733@nevyn.them.org> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00189.txt.bz2 On Thu, 17 Feb 2005 12:43:26 -0500 Daniel Jacobowitz wrote: > On Thu, Feb 17, 2005 at 09:14:15AM -0700, Kevin Buettner wrote: > > On Thu, 17 Feb 2005 18:20:43 +0300 > > "Levchenko, Vasily V" wrote: > > > > > This is a patch corrects comparing of the shared object names which > > > could be relative and absolute. > > > Situation: > > > To get tls-variable from shared library. > > > > Hi Vasily, > > > > Thanks for your patch! > > > > In the future, please send some sort of context diff, that is, patches > > generated either with "diff -u" or "diff -C". (I also like it when the > > "-p" switch is used.) > > > > I have read your patch and understand what it is doing, but before > > putting your change in, I'd first like to understand why it's necessary. > > Could you offer a bit more explanation about why it is needed? Do you > > happen to have a small test case? > > I'd also like to see a testcase. The patch compares only the basenames > of libraries (it should use lbasename from libiberty, by the way), but > it's possible to have two DSO plugins with the same basename and > different directories loaded. Actually, I've been thinking about rewriting svr4_fetch_objfile_link_map() so that it looks more like this (which will be in a forthcoming patch for remote TLS support on the FR-V): +CORE_ADDR +frv_fetch_objfile_link_map (struct objfile *objfile) +{ + struct so_list *so; + + /* Cause frv_current_sos() to be run if it hasn't been already. */ + if (main_lm_addr == 0) + solib_add (0, 0, 0, 1); + + /* frv_current_sos() will set main_lm_addr for the main executable. */ + if (objfile == symfile_objfile) + return main_lm_addr; + + /* The other link map addresses may be found by examining the list + of shared libraries. */ + for (so = NULL; ((so = so_list_iterator (so))); ) + { + if (so->objfile == objfile) + return so->lm_info->lm_addr; + } + + /* Not found! */ + return 0; +} I haven't included the full patch. There's a few other bits and pieces such as the code which sets main_lm_addr in the ``current_sos'' function. Anyway,... this method is much more efficient in that it doesn't read any memory on the target. It simply uses the list of shared objects that's already been constructed in GDB. I suspect that a rewrite like the above will handle whatever case Vasily's been running into, but I want to understand the exact scenario first. Kevin