From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12697 invoked by alias); 3 Aug 2004 14:58:03 -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 12677 invoked from network); 3 Aug 2004 14:58:02 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 3 Aug 2004 14:58:02 -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 i73Ew1e3012204 for ; Tue, 3 Aug 2004 10:58:02 -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 i73Ew1a29591; Tue, 3 Aug 2004 10:58:01 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 925542B9D; Tue, 3 Aug 2004 10:57:56 -0400 (EDT) Message-ID: <410FA7F4.6070603@gnu.org> Date: Tue, 03 Aug 2004 14:58:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040801 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> <40E5E0D2.70205@gnu.org> <20040702162210.22d67f13@saguaro> <40ED625A.7020700@gnu.org> <20040727150630.4a1492ab@saguaro> In-Reply-To: <20040727150630.4a1492ab@saguaro> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00007.txt.bz2 >>> As for the information: >>> >>> >>>> > a) The unrelocated starting address of a segment. >>> >>> Is this the offset in the object file. > > > Yeah, this should be the segment offset from the executable. > > >>> >>>> > 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?) > > > I don't think this is really needed. Though having it wouldn't hurt > if you want an additional check to make sure that you've found an > appropriate section. If GDB knows a segment is read-only, it also knows that it can cache it -> especially important for text sections. >>> >>>> > architecture here). >>> >>> f) object file path >>> >>> How does this compare to what is found in /proc/*/*map*? > > > I'm not sure where you're going with this. If we had access to the remote's /proc/*/map* (or a faked up equivalent), could we obtain the necessary information? > It's useful to have the original segment address and length in order > to find the corresponding sections. If you don't have this > information, you have to try to determine it by playing games with > things like the protection mask or perhaps the order of the entries in > the map file. I've done this before on AIX/IA64 and it was not fun. > > It's not at all clear to me though what any of this has to do with > Stephen's orignal question. Andrew