From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29036 invoked by alias); 27 Jul 2004 22:06:38 -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 29019 invoked from network); 27 Jul 2004 22:06:36 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 27 Jul 2004 22:06:36 -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 i6RM6ae3032381 for ; Tue, 27 Jul 2004 18:06:36 -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 i6RM6aa21334; Tue, 27 Jul 2004 18:06:36 -0400 Received: from localhost.localdomain (vpn50-55.rdu.redhat.com [172.16.50.55]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i6RM6ZSS017934; Tue, 27 Jul 2004 18:06:36 -0400 Received: from saguaro (saguaro.lan [192.168.64.2]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id i6RM6UHd001915; Tue, 27 Jul 2004 15:06:30 -0700 Date: Wed, 28 Jul 2004 03:04: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: <20040727150630.4a1492ab@saguaro> In-Reply-To: <40ED625A.7020700@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> <20040702162210.22d67f13@saguaro> <40ED625A.7020700@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/msg00351.txt.bz2 On Thu, 08 Jul 2004 11:03:54 -0400 Andrew Cagney wrote: > > 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 :-). To the best of my knowledge, GDB doesn't currently use the segment information contained in an executable. > > 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? Well, if we're trying to develop a protocol, we ought to at least make it extensible so that it'll handle this case if/when it becomes a problem. Aside from this concern, I have no objection to leaving it until later. > >>> 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. Yeah, this should be the segment offset from the executable. > >>>> > 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?) I don't think this is really needed. Though having it wouldn't hurt if you want an additional check to make sure that you've found an appropriate section. > >>>> > architecture here). > >>> f) object file path > > How does this compare to what is found in /proc/*/*map*? I'm not sure where you're going with this. It's useful to have the original segment address and length in order to find the corresponding sections. If you don't have this information, you have to try to determine it by playing games with things like the protection mask or perhaps the order of the entries in the map file. I've done this before on AIX/IA64 and it was not fun. It's not at all clear to me though what any of this has to do with Stephen's orignal question. Kevin