From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7180 invoked by alias); 2 Jul 2004 23:22:18 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7144 invoked from network); 2 Jul 2004 23:22:17 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 2 Jul 2004 23:22:17 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i62NMGe3004627 for ; Fri, 2 Jul 2004 19:22:16 -0400 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 i62NMG008703; Fri, 2 Jul 2004 19:22:16 -0400 Received: from localhost.localdomain (vpn50-57.rdu.redhat.com [172.16.50.57]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i62NMGc3014054; Fri, 2 Jul 2004 19:22:16 -0400 Received: from saguaro (saguaro.lan [192.168.64.2]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id i62NMAnR000302; Fri, 2 Jul 2004 16:22:10 -0700 Date: Fri, 02 Jul 2004 23:22:00 -0000 From: Kevin Buettner To: Andrew Cagney Cc: Stephen & Linda Smith , gdb@sources.redhat.com Subject: Re: shared library support hookin the remote.c Message-Id: <20040702162210.22d67f13@saguaro> In-Reply-To: <40E5E0D2.70205@gnu.org> References: <40AD1DA8.3090809@cox.net> <40AE69AB.7000004@cox.net> <20040611141424.2bed79f7@saguaro> <40DA349C.6080607@cox.net> <20040628134303.20e1cff0@saguaro> <40E09084.70108@cox.net> <20040628172120.2844044d@saguaro> <40E0CC21.1020401@cox.net> <20040701105812.44b85b9b@saguaro> <40E5C383.7060506@gnu.org> <20040702142522.038721dd@saguaro> <40E5E0D2.70205@gnu.org> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00015.txt.bz2 On Fri, 02 Jul 2004 18:25:22 -0400 Andrew Cagney wrote: > > On Fri, 02 Jul 2004 16:20:19 -0400 > > Andrew Cagney wrote: > > > >>> Kevin, how does/should the existing remote GNU/Linux target work? > >>> If we ignore the #ifdef SOLIB* code used during the initial attach, what > >>> components interact to maintain the shlibs? > > > > > > The existing GNU/Linux target knows just enough about the dynamic linker > > (struct layout and symbol names) to be able to use memory reads to do the > > entire thing. I.e, all the information that GDB needs is either obtained > > from the symbol table or from the address space of the target. > > So, from the below, there's also an event bound to a breakpoint that > triggers the entire thing? Yes. > > a) The unrelocated starting address of a segment. > > b) The length of the segment > > c) The address (relocated) of the segment. > > d) The address space associated with the segment (think harvard > > architecture here). > > e) A way of iterating over the various segments. > f) object file path Yes (thanks), I forgot that one. > For the /proc and SVR4 cases, did any of this information come from the > object file? No. The object file may appear to contain similar information (i.e. section addresses and lengths). As noted below, the information contained in (a)-(f) is used to generate relocation data for loading an object file. You will see solib-svr4.c consulting the object file. It does this to learn of certain addresses needed to location the above mentioned information and for the address upon which to set a breakpoint. > Did you have a particular harvard architecture in mind? No. We just need to provide for a way to distinguish between potentially overlapping addresses. If this is encoded in the address in such a way that there can never be any ambiguity, then field (d) is not needed. I'm not convinced there's any way to guarantee this though, which is why I suggested a separate field. > I'm still not clear whats done with the information in this table once > its created. It is used to generate relocation data for loading an object file's symbols. (See the call to symbol_file_add() in solib.c.) Given a segment obtained from (a)-(f), we need to find the corresponding object file and sections. We can then compute a relocation constant by subtracting (a) from (c) to apply (add) to addresses associated with each of the affected sections. Kevin