From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23261 invoked by alias); 18 Feb 2005 12:10:43 -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 22099 invoked from network); 18 Feb 2005 12:10:08 -0000 Received: from unknown (HELO petasus.ims.intel.com) (62.118.80.130) by sourceware.org with SMTP; 18 Feb 2005 12:10:08 -0000 Received: from mssmsxvs01.ims.intel.com (mssmsxvs01.ims.intel.com [10.125.2.23]) by petasus.ims.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id j1ICEijg010731; Fri, 18 Feb 2005 12:14:55 GMT Received: from mssmsx331.ccr.corp.intel.com ([10.125.2.16]) by mssmsxvs01.ims.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005021815090607985 ; Fri, 18 Feb 2005 15:09:06 +0300 Received: from mssmsx403.ccr.corp.intel.com ([10.125.2.52]) by mssmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Feb 2005 15:09:06 +0300 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Relative and absolute paths in link_map Date: Fri, 18 Feb 2005 16:51:00 -0000 Message-ID: <9F0F5F4271FA9140BE3E05452E3BDAFE7F336B@mssmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Levchenko, Vasily V" To: "Kevin Buettner" , "Daniel Jacobowitz" Cc: X-OriginalArrivalTime: 18 Feb 2005 12:09:06.0428 (UTC) FILETIME=[A4DDABC0:01C515B2] X-SW-Source: 2005-02/txt/msg00194.txt.bz2 Hi Kevin, >-----Original Message----- >From: Kevin Buettner [mailto:kevinb@redhat.com] >Sent: Thursday, February 17, 2005 11:09 PM [skipped] >> > >> > 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? Actually we meet with problem that for some reason gdb can't find linker's link_map for DSO with TLS variable, the problem was that for some reason comparison for the same shared object was between it relative path (stored in link_map) and absolute path in objfile->name. And because at least for linux ld.so it's impossible load two dso with the same name and different paths, so I use such way. ld.so use first founded. I'm not very common with gdb internals and libiberty, so it better of cause to use calculated lib basename. I'll try to make clear testcase ASAP. >> >> 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 =3D=3D 0) >+ solib_add (0, 0, 0, 1); >+ >+ /* frv_current_sos() will set main_lm_addr for the main executable. */ >+ if (objfile =3D=3D symfile_objfile) >+ return main_lm_addr; >+ >+ /* The other link map addresses may be found by examining the list >+ of shared libraries. */ >+ for (so =3D NULL; ((so =3D so_list_iterator (so))); ) >+ { >+ if (so->objfile =3D=3D 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