From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29612 invoked by alias); 2 Jul 2004 21:25:31 -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 29543 invoked from network); 2 Jul 2004 21:25:29 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 2 Jul 2004 21:25:29 -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 i62LPTe3010669 for ; Fri, 2 Jul 2004 17:25:29 -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 i62LPT010605; Fri, 2 Jul 2004 17:25:29 -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 i62LPSc3031118; Fri, 2 Jul 2004 17:25:28 -0400 Received: from saguaro (saguaro.lan [192.168.64.2]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id i62LPMFB032469; Fri, 2 Jul 2004 14:25:22 -0700 Date: Fri, 02 Jul 2004 21:25: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: <20040702142522.038721dd@saguaro> In-Reply-To: <40E5C383.7060506@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> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00010.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. 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. I think we need the following: 1) A way to be notified when the shared library mappings have changed 2) A way to fetch the new mappings. I think the following should be sufficient: 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. 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. Kevin