From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24616 invoked by alias); 29 Aug 2006 19:28:07 -0000 Received: (qmail 24607 invoked by uid 22791); 29 Aug 2006 19:28:06 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 29 Aug 2006 19:28:02 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GI9Fe-0007CR-Am; Tue, 29 Aug 2006 15:27:58 -0400 Date: Tue, 29 Aug 2006 19:28:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: dits365@gmail.com, gdb@sources.redhat.com Subject: Re: What exactly does "info sharedlibrary" command show? Message-ID: <20060829192758.GA27571@nevyn.them.org> Mail-Followup-To: Mark Kettenis , dits365@gmail.com, gdb@sources.redhat.com References: <20060829123954.GB12955@nevyn.them.org> <200608291914.k7TJEOPY016721@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608291914.k7TJEOPY016721@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00223.txt.bz2 On Tue, Aug 29, 2006 at 09:14:24PM +0200, Mark Kettenis wrote: > > Date: Tue, 29 Aug 2006 08:39:54 -0400 > > From: Daniel Jacobowitz > > > > On Tue, Aug 29, 2006 at 08:03:11PM +0800, chen free wrote: > > > I believe they are not the physical address, right? > > > > > > If they are virtual memory address, why they are different from the > > > info from /proc/{PID}/maps? the {PID} is the specific program process > > > ID. > > > > They are the beginning and end of ".text" in those loaded libraries. > > > > I've been thinking about changing them to be segment addresses... > > What do you mean with this? Lots of parts of GDB are section based. On modern ELF systems, this is rarely right. Instead, things should often be segment-based. A shared library is mapped according to the PT_LOAD headers, and they describe what addresses it really occupies - and what value it's relocated by, not coincidentally. Suppose we have this mapping: 2aaaaabc3000-2aaaaace4000 r-xp 00000000 fd:00 57048 /lib/libc-2.3.6.so 2aaaaace4000-2aaaaade3000 ---p 00121000 fd:00 57048 /lib/libc-2.3.6.so 2aaaaade3000-2aaaaadf8000 r--p 00120000 fd:00 57048 /lib/libc-2.3.6.so 2aaaaadf8000-2aaaaadfb000 rw-p 00135000 fd:00 57048 /lib/libc-2.3.6.so That's the PT_LOAD text segment, followed by some unmapped space between segments (for alignment), followed by the PT_LOAD data segment (part of which has been marked read only, according to PT_GNU_RELRO, readonly after relocation). It seems to me that "info shared" ought to say this library is mapped at 0x2aaaaabc3000 - 0x2aaaaaddfb000, or at least 0x2aaaaabc3000 to 0x2aaaaace4000. The latter is more portably reliable, some platforms separate the segments at relocation time, but SysV ones of course do not. Right now we say it occupies 0x00002aaaaabdf2d0 to 0x00002aaaaacc1a10. Anyway, I think it'd be a useful change, but I haven't gotten around to it yet. There's a whole bunch of related cleanups I wanted to look at simultaneously, e.g. relating to how we relocate objfiles. This one is cosmetic. It always bugs me that we show the "wrong" offsets, especially when I need to do relocation calculations by hand for some reason; I do a lot of adding and subtracting the start of .text. -- Daniel Jacobowitz CodeSourcery