From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25332 invoked by alias); 2 Jul 2004 20:20:34 -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 25077 invoked from network); 2 Jul 2004 20:20:32 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 2 Jul 2004 20:20:32 -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 i62KKWe3027262 for ; Fri, 2 Jul 2004 16:20:32 -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 i62KKV021257; Fri, 2 Jul 2004 16:20:31 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id AB98B2B9D; Fri, 2 Jul 2004 16:20:19 -0400 (EDT) Message-ID: <40E5C383.7060506@gnu.org> Date: Fri, 02 Jul 2004 20:20: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> In-Reply-To: <20040701105812.44b85b9b@saguaro> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00008.txt.bz2 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? Stephen, have you tried getting GDB to work native on your system? There are several ways to dissect this so its important to identify all the components and their interactions. Andrew PS: - I just deprecated all the existing ..._hook () calls :-) - have a look at, and think about the File I/O packets, they effectively inject events into GDB. > On Mon, 28 Jun 2004 18:55:45 -0700 > Stephen & Linda Smith wrote: > > >>> Kevin Buettner wrote: >>> >> >>>> > How does the remote target communicate the necessary details to GDB >>>> > >>>> >then? >>>> > >>>> >It sounds to me as though you want to add the hook so that you can add >>>> >a private protocol extension. >>>> > >>>> >IMO, it's better to hash out the details of a public remote protocol >>>> >extension for shared library support. >>>> > >> >>> That would be my preference, but I haven't figured out a generic way. >>> Here is the basic problem is that the >>> remote protocol has no notion of shared libraries or of segments (TEXT, >>> BSS, DATA, etc). Can someone >>> on this list think of a generic way of getting this data? > > > If you can have the stub report both the original and adjusted address > for the segments of a particular load object, GDB should be able to > determine which section(s) those segments belong to. (Take a look at the > FR-V shared library support.) > > >>> A second problem is that the number and names of the segments doesn't >>> appear to be consistent. It was for this >>> reason that I was thinking of making the protocol a target specific one >>> that supports the solib interface. > > > I wouldn't worry about the names; I don't think there'll be any need to > communicate those. As for the number of segments, the protocol should > be designed to handle an arbitrary number of segments. > > >>>> >... I'd like to first understand how communication of shared library information >>>> >between GDB and the stub is accomplished and what the protocol looks >>>> >like. >>>> > >> >>> >>> I assume you don't mean how the published protocol works. >>> >>> What I didn't in the passed, was to use a q packet. If I read the spec >>> correctly was to use that packet type to find out if >>> there were any libraries and to find out the segment addersses. >>> >>> I don't mind making it a public interface, but from the conversation >>> three years ago, I got the idea that the maintainers >>> weren't especially keen on making it part of the general (i.e remote.c) >>> code base. > > > I don't recall. However, if the protocol is general enough to be usable > by a variety of targets, I see no reason for not including it in remote.c. > After all, qSymbol support is present in remote.c and that's only used for > some thread implementations. It would be good to get buy-in from the > maintainer of remote.c before you start though. > > Kevin >