What exactly does "info sharedlibrary" command show?

What exactly does "info sharedlibrary" command show?

[chen free]

Hi, all

Recently I'm looking for a proper method of finding the memory usage
of shared library of a specific program, and from the manual of GDB, I
found "info sharedlibrary" command.

However, I'm curious about the display of its result. Does anyone know
the meaning of memory address reported by GDB? Something like:
============

From        To          Syms Read   Shared Object Library
0x005cfc00  0x006bf800  Yes         /lib/tls/libc.so.6
0x0059e7a0  0x005b010f  Yes         /lib/ld-linux.so.2

============
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.

============
Contents of "maps"

0x0059e000  0x005b3000 r-xp    00000000 fd:00 3605642    /lib/ld-2.3.4.so
0x005b3000  0x005b4000 r--p    00014000 fd:00 3605642    /lib/ld-2.3.4.so
0x005b4000  0x005b5000 rw-p    00015000 fd:00 3605642    /lib/ld-2.3.4.so
0x005bb000  0x006de000 r-xp    00000000 fd:00 3605643    /lib/tls/libc-2.3.4.so
0x006de000  0x006df000 r--p    00123000 fd:00 3605643    /lib/tls/libc-2.3.4.so
0x006df000  0x006e2000 rw-p    00124000 fd:00 3605643    /lib/tls/libc-2.3.4.so
0x006e2000  0x006e4000 rw-p    006e2000 00:00 0
0x08048000  0x08049000 r-xp    00000000 00:2f 1025644    /home/Simple
0x08049000  0x0804a000 rw-p    00000000 00:2f 1025644    /home/Simple
0xb7fe2000  0xb7fe3000 rw-p    b7fe2000 00:00 0
0xb7fff000  0xb8000000 rw-p    b7fff000 00:00 0
0xbff63000  0xc0000000 rw-p    bff63000 00:00 0
0xffffe000  0xfffff000 ---p    00000000 00:00 0
============

Thanks in advance!

BRs,
Eric

Re: What exactly does "info sharedlibrary" command show?

[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...

-- 
Daniel Jacobowitz
CodeSourcery

Re: What exactly does "info sharedlibrary" command show?

[Frederic RISS]

On Tue, 2006-08-29 at 20:03 +0800, chen free wrote:
> Recently I'm looking for a proper method of finding the memory usage
> of shared library of a specific program, 

This is a tough job, I'm not sure looking at info sharedlibrary will
help you much. 

> and from the manual of GDB, I
> found "info sharedlibrary" command.
> 
> However, I'm curious about the display of its result. Does anyone know
> the meaning of memory address reported by GDB? Something like:
> ============
> 
> >From        To          Syms Read   Shared Object Library
> 0x005cfc00  0x006bf800  Yes         /lib/tls/libc.so.6
> 0x0059e7a0  0x005b010f  Yes         /lib/ld-linux.so.2
> 
> ============
> I believe they are not the physical address, right?

They are the start/end (virtual) addresses of the library .text section.

> ============
> Contents of "maps"
> 0x005bb000  0x006de000 r-xp    00000000 fd:00 3605643    /lib/tls/libc-2.3.4.so

If you take this as an example, you should find out that 0x005cfc00 -
0x005bb000 gives you the .text section load addr (check in the elf file
using objdump -h or readelf -s).

Fred.

Re: What exactly does "info sharedlibrary" command show?

[chen free]

Thanks, Jacobowitz and Fred.

Yes, it a tough job, maybe I have to dump the memory image and look
into it. BTW, the "dump" command of GDB is also only able to dump
process' own virtual memory space ? Because when I try to dump
physical memory address range, the result is all zeros....I tried this
on 2.6 kernel

Looking forward to your reply.

Regards,
Eric

2006/8/29, Frederic RISS <frederic.riss@st.com>:
>
> On Tue, 2006-08-29 at 20:03 +0800, chen free wrote:
> > Recently I'm looking for a proper method of finding the memory usage
> > of shared library of a specific program,
>
> This is a tough job, I'm not sure looking at info sharedlibrary will
> help you much.
>
> > and from the manual of GDB, I
> > found "info sharedlibrary" command.
> >
> > However, I'm curious about the display of its result. Does anyone know
> > the meaning of memory address reported by GDB? Something like:
> > ============
> >
> > >From        To          Syms Read   Shared Object Library
> > 0x005cfc00  0x006bf800  Yes         /lib/tls/libc.so.6
> > 0x0059e7a0  0x005b010f  Yes         /lib/ld-linux.so.2
> >
> > ============
> > I believe they are not the physical address, right?
>
> They are the start/end (virtual) addresses of the library .text section.
>
> > ============
> > Contents of "maps"
> > 0x005bb000  0x006de000 r-xp    00000000 fd:00 3605643    /lib/tls/libc-2.3.4.so
>
> If you take this as an example, you should find out that 0x005cfc00 -
> 0x005bb000 gives you the .text section load addr (check in the elf file
> using objdump -h or readelf -s).
>
> Fred.
>
>

Re: What exactly does "info sharedlibrary" command show?

[Frederic RISS]

On Tue, 2006-08-29 at 21:00 +0800, chen free wrote:
> Yes, it a tough job, maybe I have to dump the memory image and look
> into it. BTW, the "dump" command of GDB is also only able to dump
> process' own virtual memory space ? Because when I try to dump
> physical memory address range, the result is all zeros....I tried this
> on 2.6 kernel

Usually a process has only access to its virtual address space, thus
accessing physical memory ranges might not even be possible.
Even if you can access the physical memory, it's most of the time just
pointless because the data is loaded in memory only on-demand (upon a
pagefault). 
That's why I said it's a tough job. Memory usage is hard to define when
you deal with code that is shared among processes and loaded only when
necessary...

But we're diverging from GDB. I don't know exactly what 'memory usage'
you want to monitor, but maybe GDB isn't the right tool for what you
want to do (debugger vs profiler?)

Fred.

Re: What exactly does "info sharedlibrary" command show?

[chen free]

What I'm interested in is the snap-shot of physical memory usage of
shared libraries. Yes, maybe I should try other tools.

Anyway, thanks, Fred.

Regards,
Eric

2006/8/29, Frederic RISS <frederic.riss@st.com>:
> On Tue, 2006-08-29 at 21:00 +0800, chen free wrote:
> > Yes, it a tough job, maybe I have to dump the memory image and look
> > into it. BTW, the "dump" command of GDB is also only able to dump
> > process' own virtual memory space ? Because when I try to dump
> > physical memory address range, the result is all zeros....I tried this
> > on 2.6 kernel
>
> Usually a process has only access to its virtual address space, thus
> accessing physical memory ranges might not even be possible.
> Even if you can access the physical memory, it's most of the time just
> pointless because the data is loaded in memory only on-demand (upon a
> pagefault).
> That's why I said it's a tough job. Memory usage is hard to define when
> you deal with code that is shared among processes and loaded only when
> necessary...
>
> But we're diverging from GDB. I don't know exactly what 'memory usage'
> you want to monitor, but maybe GDB isn't the right tool for what you
> want to do (debugger vs profiler?)
>
> Fred.
>
>

Re: What exactly does "info sharedlibrary" command show?

[Mark Kettenis]

> 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?

Re: What exactly does "info sharedlibrary" command show?

[Daniel Jacobowitz]

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

Re: What exactly does "info sharedlibrary" command show?

[Mark Kettenis]

> Date: Tue, 29 Aug 2006 15:27:58 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> 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.

OK, that's what I was afraid of ;-).

> 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).

Ah, but there can be more than two PT_LOAD segments.  On OpenBSD/i386
we have for example:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x81e06 0x81e06 R E 0x1000
  LOAD           0x082000 0x20000000 0x20000000 0x0c3e2 0x0c3e2 R   0x1000
  LOAD           0x08f000 0x2000d000 0x2000d000 0x02c04 0x02c04 RW  0x1000
  LOAD           0x091c04 0x20010c04 0x20010c04 0x00c84 0x00c84 RW  0x1000
  LOAD           0x0928a0 0x200128a0 0x200128a0 0x00000 0x1e660 RW  0x1000
  DYNAMIC        0x091b64 0x2000fb64 0x2000fb64 0x000a0 0x000a0 RW  0x4

Note the big gap between the executable segment and the other
segments.  This is true for all shared libraries on OpenBSD/i386 and
the idea is to map all executable code below a certain virtual address
and all non-executable segments above that address.  That makes it
possible to guarantee that writable pages will never be executable,
something we call W^X which is similar to PAX (but works instead).
The result is that shared libraries will sort of overlap.

> 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.

The first approach would lead to much confusion since it would lead to
seemingly overlapping shared libraries on OpenBSD/i386.  The latter
approach is better in that sense.

> Right now we say it occupies 0x00002aaaaabdf2d0 to 0x00002aaaaacc1a10.

I like this though, since I mostly search the list for code addresses.

> 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.

True.  Somehow we should make the load address of a shared library
available.

Mark

Re: What exactly does "info sharedlibrary" command show?

[Daniel Jacobowitz]

On Tue, Aug 29, 2006 at 10:05:22PM +0200, Mark Kettenis wrote:
> > 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.
> 
> The first approach would lead to much confusion since it would lead to
> seemingly overlapping shared libraries on OpenBSD/i386.  The latter
> approach is better in that sense.

Right.  As I said, I knew that there were systems where you were
limited to the first segment for this purpose, though I didn't know W^X
used this.

> > Right now we say it occupies 0x00002aaaaabdf2d0 to 0x00002aaaaacc1a10.
> 
> I like this though, since I mostly search the list for code addresses.

Really?  Even if I'm searching for code addresses, I dislike this,
because it has more noise and fewer significant bits.

Given this I have a hard time finding anything visually:

0x00002aaaaabd6910  0x00002aaaaabf1e58  Yes /lib/libreadline.so.5
0x00002aaaaad20ef0  0x00002aaaaad43cc8  Yes /usr/lib/libncurses.so.5
0x00002aaaaae61dd0  0x00002aaaaaea22b8  Yes /lib/libm.so.6
0x00002aaaaafe2000  0x00002aaaaafe2978  Yes /lib/libdl.so.2
0x00002aaaab1002d0  0x00002aaaab1e2a10  Yes /lib/libc.so.6
0x00002aaaaaaaba80  0x00002aaaaaabc857  Yes /lib64/ld-linux-x86-64.so.2
0x00002aaaab50a8e0  0x00002aaaab50dce8  Yes /lib/libthread_db.so.1

I find this much easier:

0x00002aaaaabd6000  0x00002aaaaabf2000  Yes /lib/libreadline.so.5
0x00002aaaaad20000  0x00002aaaaad44000  Yes /usr/lib/libncurses.so.5
0x00002aaaaae61000  0x00002aaaaaea3000  Yes /lib/libm.so.6
0x00002aaaaafe2000  0x00002aaaaafe3000  Yes /lib/libdl.so.2
0x00002aaaab100000  0x00002aaaab1e3000  Yes /lib/libc.so.6
0x00002aaaaaaab000  0x00002aaaaaabd000  Yes /lib64/ld-linux-x86-64.so.2
0x00002aaaab50a000  0x00002aaaab50e000  Yes /lib/libthread_db.so.1

But, it's not a big deal.  If you actually prefer the way it is now,
I guess I'll leave it alone after all.

> True.  Somehow we should make the load address of a shared library
> available.

Should we use segments in "info files" when available?

-- 
Daniel Jacobowitz
CodeSourcery

Re: What exactly does "info sharedlibrary" command show?

[Steve Eaton]

Daniel,
           I appologise if this is common knowledge, i just recently
signed up to the gdb group.  

While on the shared library subject.   We are struggling with how to
deal with them here.  When I get a core from a customer they can have
100's of  shared libraries of varying versions.  An examaple would be 

Core was generated by `/usr/sbin/ndsd'.
Reading symbols from /usr/lib/libccs2.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/sbin/../lib/libccs2.so
Reading symbols from /usr/lib/nds-modules/libdsloader.so.1...(no
debugging symbols found)...done.
Loaded symbols for /usr/lib/nds-modules/libdsloader.so.1
Reading symbols from /usr/lib/libsal.so.1...done.
Loaded symbols for /usr/sbin/../lib/libsal.so.1
Reading symbols from /usr/lib/libdsutil.so.1...done.
Loaded symbols for /usr/sbin/../lib/libdsutil.so.1
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/tls/libpthread.so.0...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/tls/librt.so.1...done.
Loaded symbols for /lib/tls/librt.so.1
Reading symbols from /lib/tls/libm.so.6...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/nds-modules/libncpengine.so...done.
Loaded symbols for /usr/lib//nds-modules/libncpengine.so
Reading symbols from /usr/lib/nds-modules/libncpns.so...done.
Loaded symbols for /usr/lib/nds-modules/libncpns.so
Reading symbols from /usr/lib/libntls.so...done.
Loaded symbols for /usr/sbin/../lib/libntls.so
Reading symbols from
/usr/lib/nds-modules/libsmbsharemodes.so.0...done.
Loaded symbols for /usr/lib/nds-modules/libsmbsharemodes.so.0
Reading symbols from /usr/lib/libstdc++.so.5...done.
Loaded symbols for /usr/sbin/../lib/libstdc++.so.5
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /usr/lib/nds-modules/libnds.so.1...done.
Loaded symbols for /usr/lib/nds-modules/libnds.so.1
Reading symbols from /usr/lib/libflaim.so.1...done.
Loaded symbols for /usr/lib/nds-modules/../libflaim.so.1
Reading symbols from /usr/lib/gconv/UNICODE.so...done.
Loaded symbols for /usr/lib/gconv/UNICODE.so
Reading symbols from /usr/lib/gconv/IBM437.so...done.
Loaded symbols for /usr/lib/gconv/IBM437.so
Reading symbols from /usr/lib/nds-modules/libmasv.so...done.
Loaded symbols for /usr/lib//nds-modules/libmasv.so
Reading symbols from /usr/lib/nds-modules/libhttpstk.so...done.
Loaded symbols for /usr/lib//nds-modules/libhttpstk.so
Reading symbols from /usr/lib/nds-modules/libgams.so...done.
Loaded symbols for /usr/lib//nds-modules/libgams.so
Reading symbols from /usr/lib/nds-modules/libnmas.so...done.
Loaded symbols for /usr/lib//nds-modules/libnmas.so
Reading symbols from /usr/lib/nds-modules/libspmdclnt.so...done.
Loaded symbols for /usr/lib//nds-modules/libspmdclnt.so
Reading symbols from /usr/lib/nds-modules/libniciext.so...done.
Loaded symbols for /usr/lib//nds-modules/libniciext.so
Reading symbols from /usr/lib/nds-modules/libsnmp.so...done.
Loaded symbols for /usr/lib//nds-modules/libsnmp.so
Reading symbols from /usr/lib/nds-modules/libhconserv.so...done.
Loaded symbols for /usr/lib//nds-modules/libhconserv.so
Reading symbols from /usr/lib/nds-modules/libnldap.so...done.
Loaded symbols for /usr/lib//nds-modules/libnldap.so
Reading symbols from /usr/lib/nds-modules/libimon.so...done.
Loaded symbols for /usr/lib//nds-modules/libimon.so
Reading symbols from /usr/lib/liblangmani.so...done.
Loaded symbols for /usr/lib//nds-modules/../liblangmani.so
Reading symbols from /usr/lib/libxi18n.so...done.
Loaded symbols for /usr/lib//nds-modules/../libxi18n.so
Reading symbols from /usr/lib/libicui18n.so.21...done.
Loaded symbols for /usr/lib//nds-modules/../libicui18n.so.21
Reading symbols from /usr/lib/libicuuc.so.21...done.
Loaded symbols for /usr/lib//nds-modules/../libicuuc.so.21
Reading symbols from /usr/lib/libicudata.so.21...done.
Loaded symbols for /usr/lib//nds-modules/../libicudata.so.21
Reading symbols from /usr/lib/nds-modules/libembox.so...done.
Loaded symbols for /usr/lib//nds-modules/libembox.so
Reading symbols from /usr/lib/libXis11.so.1...done.
Loaded symbols for /usr/sbin/../lib/libXis11.so.1
Reading symbols from /usr/lib/nds-modules/embox/liblangman.so...done.
Loaded symbols for /usr/lib//nds-modules/embox/liblangman.so
Reading symbols from /usr/lib/nds-modules/embox/libht2soap.so...done.
Loaded symbols for /usr/lib//nds-modules/embox/libht2soap.so
Reading symbols from /usr/lib/nds-modules/embox/libeMBoxMgr.so...done.
Loaded symbols for /usr/lib//nds-modules/embox/libeMBoxMgr.so
Reading symbols from /usr/lib/libemboxmsg.so...done.
Loaded symbols for /usr/sbin/../lib/libemboxmsg.so
Reading symbols from /usr/lib/nds-modules/embox/librss.so...done.
Loaded symbols for /usr/lib//nds-modules/embox/librss.so
Reading symbols from /usr/lib/nds-modules/embox/libemsecure.so...done.
Loaded symbols for /usr/lib//nds-modules/embox/libemsecure.so
Reading symbols from /usr/lib/nds-modules/libstatuslg.so...done.
Loaded symbols for /usr/lib//nds-modules/libstatuslg.so
Reading symbols from
/usr/lib/nds-modules/embox/emtools/liblogger.so...done.
Loaded symbols for /usr/lib//nds-modules/embox/emtools/liblogger.so
Reading symbols from /var/nds/nmas-methods/certlsmlin.so...done.
Loaded symbols for /var/nds/nmas-methods/certlsmlin.so
Reading symbols from /usr/lib/libnpkit.so.2...done.
Loaded symbols for /usr/lib/libnpkit.so.2
Reading symbols from /usr/lib/libldapsdk.so.0...done.
Loaded symbols for /usr/lib/libldapsdk.so.0
Reading symbols from
/usr/lib/nds-modules/embox/emtools/libschematl.so...done.
Loaded symbols for /usr/lib//nds-modules/embox/emtools/libschematl.so
Reading symbols from
/usr/lib/nds-modules/embox/emtools/libmergetl.so...done.
Loaded symbols for /usr/lib//nds-modules/embox/emtools/libmergetl.so
Reading symbols from
/usr/lib/nds-modules/embox/emtools/libbackuptl.so...done.
Loaded symbols for /usr/lib//nds-modules/embox/emtools/libbackuptl.so
Reading symbols from /usr/lib/nds-modules/libbackupcr.so...done.
Loaded symbols for /usr/lib//nds-modules/libbackupcr.so
Reading symbols from
/usr/lib/nds-modules/embox/emtools/librepairtl.so...done.
Loaded symbols for /usr/lib//nds-modules/embox/emtools/librepairtl.so
Reading symbols from
/usr/lib/nds-modules/embox/emtools/libservictl.so...done.
Loaded symbols for /usr/lib//nds-modules/embox/emtools/libservictl.so
Reading symbols from /usr/lib/nds-modules/libpkiserver.so...done.
Loaded symbols for /usr/lib//nds-modules/libpkiserver.so
Reading symbols from /var/nds/nmas-methods/certlcmlin.so...done.
Loaded symbols for /var/nds/nmas-methods/certlcmlin.so
Reading symbols from /usr/lib/libslp.so.1...done.
Loaded symbols for /usr/lib/nds-modules/../libslp.so.1
Reading symbols from /usr/lib/libcrypto.so.0.9.7...done.
Loaded symbols for /usr/sbin/../lib/libcrypto.so.0.9.7
Reading symbols from /var/nds/nmas-methods/crlsmlin.so...done.
Loaded symbols for /var/nds/nmas-methods/crlsmlin.so
Reading symbols from /var/nds/nmas-methods/lsmmd5lin.so...done.
Loaded symbols for /var/nds/nmas-methods/lsmmd5lin.so
Reading symbols from /var/nds/nmas-methods/lcmmd5lin.so...done.
Loaded symbols for /var/nds/nmas-methods/lcmmd5lin.so
Reading symbols from /var/nds/nmas-methods/epwdlsmlin.so...done.
Loaded symbols for /var/nds/nmas-methods/epwdlsmlin.so
Reading symbols from /var/nds/nmas-methods/etadvlsmlin.so...done.
Loaded symbols for /var/nds/nmas-methods/etadvlsmlin.so
Reading symbols from /usr/lib/libnpkiapi.so.2...done.
Loaded symbols for /usr/lib/libnpkiapi.so.2
Reading symbols from /var/nds/nmas-methods/pwdlsmlin.so...done.
Loaded symbols for /var/nds/nmas-methods/pwdlsmlin.so
Reading symbols from /var/nds/nmas-methods/pwdlcmlin.so...done.
Loaded symbols for /var/nds/nmas-methods/pwdlcmlin.so
Reading symbols from /var/nds/nmas-methods/usclsmlin.so...done.
Loaded symbols for /var/nds/nmas-methods/usclsmlin.so
Reading symbols from /var/nds/nmas-methods/x509alsmlin.so...done.
Loaded symbols for /var/nds/nmas-methods/x509alsmlin.so
Reading symbols from /usr/lib/liblburp.so...done.
Loaded symbols for /usr/lib//liblburp.so
Reading symbols from /usr/lib/nds-modules/libldapxs.so...done.
Loaded symbols for /usr/lib//nds-modules/libldapxs.so
Reading symbols from /usr/lib/nds-modules/libnmasldap.so...done.
Loaded symbols for /usr/lib//nds-modules/libnmasldap.so
Reading symbols from /var/nds/nmas-methods/cpwdplsmlin.so...done.
Loaded symbols for /var/nds/nmas-methods/cpwdplsmlin.so
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/nds-modules/libsasl.so...done.
Loaded symbols for /usr/lib//nds-modules/libsasl.so

Now imagine you had to do something useful with the said core file.  I
have to try and match up all of the above shared libraries of various
versions, or try and get fancy and parse the output and tar up the users
files.  You don't have the luxury of having the -g in every library that
is run everywhere.   

The best I have been able to do is to get the user to open the file in
gdb and do a 
thread apply all bt, in that way I can fiddle around with different
versions of shared library files until the stacks look right.

Is there an option that a person could configure to include the so
files in the core or something equivelent ?

Thanks,
Steve

Re: What exactly does "info sharedlibrary" command show?

[Mark Kettenis]

> Date: Tue, 29 Aug 2006 16:12:06 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> Right.  As I said, I knew that there were systems where you were
> limited to the first segment for this purpose, though I didn't know W^X
> used this.

We play tricks we the i386's segment registers to accomplish this.  We
set up a segment descriptor for %cs that doesn't map the complete
virtual address space.  Then we have to make sure that all executable
segments fall into the region covered by that segment descriptor and
all writable sections are outside that region.

> > > Right now we say it occupies 0x00002aaaaabdf2d0 to 0x00002aaaaacc1a10.
> > 
> > I like this though, since I mostly search the list for code addresses.
> 
> Really?  Even if I'm searching for code addresses, I dislike this,
> because it has more noise and fewer significant bits.
> 
> Given this I have a hard time finding anything visually:
> 
> 0x00002aaaaabd6910  0x00002aaaaabf1e58  Yes /lib/libreadline.so.5
> 0x00002aaaaad20ef0  0x00002aaaaad43cc8  Yes /usr/lib/libncurses.so.5
> 0x00002aaaaae61dd0  0x00002aaaaaea22b8  Yes /lib/libm.so.6
> 0x00002aaaaafe2000  0x00002aaaaafe2978  Yes /lib/libdl.so.2
> 0x00002aaaab1002d0  0x00002aaaab1e2a10  Yes /lib/libc.so.6
> 0x00002aaaaaaaba80  0x00002aaaaaabc857  Yes /lib64/ld-linux-x86-64.so.2
> 0x00002aaaab50a8e0  0x00002aaaab50dce8  Yes /lib/libthread_db.so.1
> 
> I find this much easier:
> 
> 0x00002aaaaabd6000  0x00002aaaaabf2000  Yes /lib/libreadline.so.5
> 0x00002aaaaad20000  0x00002aaaaad44000  Yes /usr/lib/libncurses.so.5
> 0x00002aaaaae61000  0x00002aaaaaea3000  Yes /lib/libm.so.6
> 0x00002aaaaafe2000  0x00002aaaaafe3000  Yes /lib/libdl.so.2
> 0x00002aaaab100000  0x00002aaaab1e3000  Yes /lib/libc.so.6
> 0x00002aaaaaaab000  0x00002aaaaaabd000  Yes /lib64/ld-linux-x86-64.so.2
> 0x00002aaaab50a000  0x00002aaaab50e000  Yes /lib/libthread_db.so.1

Yup, if you can guarantee that the first segment indeed includes all
the .text code, the latter is much better.

> But, it's not a big deal.  If you actually prefer the way it is now,
> I guess I'll leave it alone after all.
> 
> > True.  Somehow we should make the load address of a shared library
> > available.
> 
> Should we use segments in "info files" when available?

Not sure.  For me, the sections are much more useful, and the segments
wouldn't really add much information.

Re: What exactly does "info sharedlibrary" command show?

[Daniel Jacobowitz]

On Tue, Aug 29, 2006 at 03:05:19PM -0600, Steve Eaton wrote:
> Now imagine you had to do something useful with the said core file.  I
> have to try and match up all of the above shared libraries of various
> versions, or try and get fancy and parse the output and tar up the users
> files.  You don't have the luxury of having the -g in every library that
> is run everywhere.   
> 
> The best I have been able to do is to get the user to open the file in
> gdb and do a 
> thread apply all bt, in that way I can fiddle around with different
> versions of shared library files until the stacks look right.
> 
> Is there an option that a person could configure to include the so
> files in the core or something equivelent ?

Not that I know of, but it's been suggested for at least Linux in the
past.  You may wish to ask your OS vendor to implement this.

-- 
Daniel Jacobowitz
CodeSourcery

Re: What exactly does "info sharedlibrary" command show?

[Daniel Jacobowitz]

On Tue, Aug 29, 2006 at 11:07:55PM +0200, Mark Kettenis wrote:
> Yup, if you can guarantee that the first segment indeed includes all
> the .text code, the latter is much better.

How would you feel about "the segment containing .text", then?

Actually, I'd probably try first to pick out "the segment with exec
permission", and only if there was none or more than one look for a
section named .text; I see that this would work for OpenBSD too. I'm
trying as a general background task to decrease reliance on section
names; for instance, the ARM compilers only call this ER_RO.

-- 
Daniel Jacobowitz
CodeSourcery

Re: What exactly does "info sharedlibrary" command show?

[chen free]

Hi, Jacobowitz


2006/8/30, Daniel Jacobowitz <drow@false.org>:
> Given this I have a hard time finding anything visually:
>
> 0x00002aaaaabd6910  0x00002aaaaabf1e58  Yes /lib/libreadline.so.5
> 0x00002aaaaad20ef0  0x00002aaaaad43cc8  Yes /usr/lib/libncurses.so.5
> 0x00002aaaaae61dd0  0x00002aaaaaea22b8  Yes /lib/libm.so.6
> 0x00002aaaaafe2000  0x00002aaaaafe2978  Yes /lib/libdl.so.2
> 0x00002aaaab1002d0  0x00002aaaab1e2a10  Yes /lib/libc.so.6
> 0x00002aaaaaaaba80  0x00002aaaaaabc857  Yes /lib64/ld-linux-x86-64.so.2
> 0x00002aaaab50a8e0  0x00002aaaab50dce8  Yes /lib/libthread_db.so.1
>
> I find this much easier:
>
> 0x00002aaaaabd6000  0x00002aaaaabf2000  Yes /lib/libreadline.so.5
> 0x00002aaaaad20000  0x00002aaaaad44000  Yes /usr/lib/libncurses.so.5
> 0x00002aaaaae61000  0x00002aaaaaea3000  Yes /lib/libm.so.6
> 0x00002aaaaafe2000  0x00002aaaaafe3000  Yes /lib/libdl.so.2
> 0x00002aaaab100000  0x00002aaaab1e3000  Yes /lib/libc.so.6
> 0x00002aaaaaaab000  0x00002aaaaaabd000  Yes /lib64/ld-linux-x86-64.so.2
> 0x00002aaaab50a000  0x00002aaaab50e000  Yes /lib/libthread_db.so.1

So you mean in "0x00002aaaaabd6910  0x00002aaaaabf1e58  Yes
/lib/libreadline.so.5" it's the real address of code (.text) segment?

> > True.  Somehow we should make the load address of a shared library
> > available.
>
> Should we use segments in "info files" when available?

Are the "info files" reported the same result as "readelf" or "info shared"?

> --
> Daniel Jacobowitz
> CodeSourcery
>


Regards,
Eric

Re: What exactly does "info sharedlibrary" command show?

[Daniel Jacobowitz]

On Wed, Aug 30, 2006 at 01:21:53PM +0800, chen free wrote:
> So you mean in "0x00002aaaaabd6910  0x00002aaaaabf1e58  Yes
> /lib/libreadline.so.5" it's the real address of code (.text) segment?

The .text section, not segment.

> Are the "info files" reported the same result as "readelf" or "info shared"?

Sort of.  I don't know what you're asking.

-- 
Daniel Jacobowitz
CodeSourcery

Re: What exactly does "info sharedlibrary" command show?

[chen free]

Thanks, buddies, any way, now I'm clear about the "info shared" command :-)

And "info files", "readelf" are more or less the same, and can provide
more infomation than "info shared".

Regards,
Eric

2006/8/30, Daniel Jacobowitz <drow@false.org>:
> On Wed, Aug 30, 2006 at 01:21:53PM +0800, chen free wrote:
> > So you mean in "0x00002aaaaabd6910  0x00002aaaaabf1e58  Yes
> > /lib/libreadline.so.5" it's the real address of code (.text) segment?
>
> The .text section, not segment.
>
> > Are the "info files" reported the same result as "readelf" or "info shared"?
>
> Sort of.  I don't know what you're asking.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>