From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3036 invoked by alias); 2 Jul 2004 22:25:35 -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 2985 invoked from network); 2 Jul 2004 22:25:35 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 2 Jul 2004 22:25:35 -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 i62MPYe3024177 for ; Fri, 2 Jul 2004 18:25:35 -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 i62MPY027080; Fri, 2 Jul 2004 18:25:34 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 5DB012B9D; Fri, 2 Jul 2004 18:25:22 -0400 (EDT) Message-ID: <40E5E0D2.70205@gnu.org> Date: Fri, 02 Jul 2004 22:25: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> In-Reply-To: <20040702142522.038721dd@saguaro> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00011.txt.bz2 > 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? > I am comfortable with this arrangement for GNU/Linux, but it isn't > adequate for all shared library scenarios. E.g, I've worked on shared > library mechanisms in the past which used files from /proc to specify > the mappings. It would be good if we could come up with a protocol > extension whereby the target supplies the information that GDB > needs. (See qPart) > 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 For the /proc and SVR4 cases, did any of this information come from the object file? Did you have a particular harvard architecture in mind? I'm still not clear whats done with the information in this table once its created. > solib-svr4.c does (1) by using breakpoints; i.e. a breakpoint is set > on a dynamic linker function which is always called when the mappings > change. It does all of (2) by reading target memory. Andrew