This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: What exactly does "info sharedlibrary" command show?
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 <drow@false.org>
> >
> > 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