From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18797 invoked by alias); 13 Jul 2004 00:19:39 -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 18788 invoked from network); 13 Jul 2004 00:19:38 -0000 Received: from unknown (HELO fed1rmmtao08.cox.net) (68.230.241.31) by sourceware.org with SMTP; 13 Jul 2004 00:19:38 -0000 Received: from ip68-3-5-250.ph.ph.cox.net ([68.3.5.250]) by fed1rmmtao08.cox.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with SMTP id <20040713001936.SNZX28232.fed1rmmtao08.cox.net@ip68-3-5-250.ph.ph.cox.net> for ; Mon, 12 Jul 2004 20:19:36 -0400 Received: (qmail 24290 invoked from network); 13 Jul 2004 00:15:22 -0000 Received: from sslp-stephens.smith.home (HELO cox.net) (192.168.1.50) by ip68-3-5-250.ph.ph.cox.net with SMTP; 13 Jul 2004 00:15:22 -0000 Message-ID: <40F32979.4060102@cox.net> Date: Tue, 13 Jul 2004 20:15:00 -0000 From: "Stephen P. Smith" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Andrew Cagney CC: Kevin Buettner , 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> <40E5D0AB.7010407@cox.net> <40E5E1F6.4090203@gnu.org> In-Reply-To: <40E5E1F6.4090203@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00122.txt.bz2 Andrew Cagney wrote: >> The system that I am working on has an OS that is used for embedded >> applications. Therefore the only >> way to debug is by a remote protocol or by emulator. The host type >> is either i686-pc-elf or >> powerpc-motorola-elf >> >> As for native on my host - usually I am running on my cygwin box and >> things are working fine there. > > > But assuming you could, what mechanisms would you use to implement it? > :-) Sorry, but I had to modify the old (non-gdb supported) implementation which had a side benifit of reminding me what needed done. Note that I am not saying that this has to be the protocol, just that I know it works with a minimal amount of network bandwith. Also note, that because of number 2 below, this support is backward compatible to older stubs or to future stubs that don't care to support shared libraries. 1) Send a packet to the remote target asking if there are any shared libraries. 2) If the target sends back a '\0', then GDB knows that the target doesn't support this protocol and won't and the rest of this protocol is unused for the remainder of the debugging session. This keeps the traffic to a minimum for stubs that don't support shared libraries (and we have a couple). 3) If the stub supports Step 1 it replies with a flag character. We used '0' for none and '1' to not that there are some. 4) If a '1' is returned in Step 3, then the following happens until there are no more libraries to report. The stub will only return the information for one shared library at a time so as not to over run a buffer in GDB. - a packet is sent asking for the shared library information. - The stub returns the library name and its location in memory which GDB uses to then load the symbol table correctly. There are a couple of things that should be taken into acount for remote stubs. 1) The remote OS may not provide a way for the stub to get an interrupt or hook the library loading code but some may. The OS I am involved with has that code in read-only memory. 2) The OS may have already loaded the libraries by the time the stub gets control of the the process. It is for these two reasons that we don't use the breakpoint method that kevin is talking about. I do like it for systems that can support it - however. sps sps