From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3658 invoked by alias); 8 Jul 2004 15:04:10 -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 3647 invoked from network); 8 Jul 2004 15:04:09 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Jul 2004 15:04:09 -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 i68F48e3029923 for ; Thu, 8 Jul 2004 11:04:08 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i68F47014325; Thu, 8 Jul 2004 11:04:07 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2B7E52B9D; Thu, 8 Jul 2004 11:03:55 -0400 (EDT) Message-ID: <40ED625A.7020700@gnu.org> Date: Thu, 08 Jul 2004 15:04:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Kevin Buettner Cc: Stephen & Linda Smith , gdb@sources.redhat.com Subject: Re: shared library support hookin the remote.c 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> <20040702162210.22d67f13@saguaro> In-Reply-To: <20040702162210.22d67f13@saguaro> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00068.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. An object file (at least elf) contains segment information. I guess this is ignored? (For those that are wondering, there's a subtle difference between segment and section :-). > 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. Can we worry about this when it becomes a problem? >>> 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. So its: - an event indicating that the link map changed - in responce the solib code fetches the entire link map - the link map is merged against the current local cache - the objfile code is notified of any segment changes It can be sliced 'n' diced at least two ways: - at the objfile interface -> the protocol pushes changes to the link map - a the solib interface -> the protocol pushes a ``something solib like happened'', and then the solib code pulls the link map. If things are being done at this lower level, the protocol could even pass across the address/symbol at which the link map breakpoint should be inserted? As for the information: >>>> > a) The unrelocated starting address of a segment. Is this the offset in the object file. >>>> > b) The length of the segment >>>> > c) The address (relocated) of the segment. >>>> > d) The address space associated with the segment (think harvard Rather than this is the protection mask needed (r,w,x?) >>>> > architecture here). >>> f) object file path How does this compare to what is found in /proc/*/*map*? Andrew