From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4970 invoked by alias); 14 Jul 2004 18:08:19 -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 4953 invoked from network); 14 Jul 2004 18:08:18 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 14 Jul 2004 18:08:18 -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 i6EI8He3011465 for ; Wed, 14 Jul 2004 14:08:18 -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 i6EI8H006493; Wed, 14 Jul 2004 14:08:17 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3CC342B9D; Wed, 14 Jul 2004 14:08:05 -0400 (EDT) Message-ID: <40F57685.7020108@gnu.org> Date: Wed, 14 Jul 2004 18:30: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: "Stephen P. Smith" 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> <40F32979.4060102@cox.net> In-Reply-To: <40F32979.4060102@cox.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00141.txt.bz2 >> 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. Good :-) > 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. So each time the inferior stops, GDB will need to re-poll for shlib changes? Can the stub instead generate a packet, very like the recently added F (File I/O) indicating that the link map changed (and what)? I previously wrote: > 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. > >>>>> > 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?) > >>>>> > architecture here). >>>> f) object file path > > How does this compare to what is found in /proc/*/*map*? The other is to have a custom xxx-shlib hooked up to inferior stopped that queries for the stuff you describe. It could probably be tunneled as a TARGET_OBJECT_KOD packet. Andrew