* What exactly does "info sharedlibrary" command show?
@ 2006-08-29 12:03 chen free
2006-08-29 12:40 ` Daniel Jacobowitz
2006-08-29 12:47 ` Frederic RISS
0 siblings, 2 replies; 17+ messages in thread
From: chen free @ 2006-08-29 12:03 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 12:03 What exactly does "info sharedlibrary" command show? chen free @ 2006-08-29 12:40 ` Daniel Jacobowitz 2006-08-29 19:15 ` Mark Kettenis 2006-08-29 12:47 ` Frederic RISS 1 sibling, 1 reply; 17+ messages in thread From: Daniel Jacobowitz @ 2006-08-29 12:40 UTC (permalink / raw) To: chen free; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 12:40 ` Daniel Jacobowitz @ 2006-08-29 19:15 ` Mark Kettenis 2006-08-29 19:28 ` Daniel Jacobowitz 0 siblings, 1 reply; 17+ messages in thread From: Mark Kettenis @ 2006-08-29 19:15 UTC (permalink / raw) To: drow; +Cc: dits365, gdb > 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 19:15 ` Mark Kettenis @ 2006-08-29 19:28 ` Daniel Jacobowitz 2006-08-29 20:06 ` Mark Kettenis 0 siblings, 1 reply; 17+ messages in thread From: Daniel Jacobowitz @ 2006-08-29 19:28 UTC (permalink / raw) To: Mark Kettenis; +Cc: dits365, gdb 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 19:28 ` Daniel Jacobowitz @ 2006-08-29 20:06 ` Mark Kettenis 2006-08-29 20:12 ` Daniel Jacobowitz 0 siblings, 1 reply; 17+ messages in thread From: Mark Kettenis @ 2006-08-29 20:06 UTC (permalink / raw) To: drow; +Cc: mark.kettenis, dits365, gdb > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 20:06 ` Mark Kettenis @ 2006-08-29 20:12 ` Daniel Jacobowitz 2006-08-29 21:05 ` Steve Eaton ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Daniel Jacobowitz @ 2006-08-29 20:12 UTC (permalink / raw) To: Mark Kettenis; +Cc: dits365, gdb 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 20:12 ` Daniel Jacobowitz @ 2006-08-29 21:05 ` Steve Eaton 2006-08-29 21:17 ` Daniel Jacobowitz 2006-08-29 21:08 ` Mark Kettenis 2006-08-30 5:22 ` chen free 2 siblings, 1 reply; 17+ messages in thread From: Steve Eaton @ 2006-08-29 21:05 UTC (permalink / raw) To: Daniel Jacobowitz, Mark Kettenis; +Cc: dits365, gdb 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 21:05 ` Steve Eaton @ 2006-08-29 21:17 ` Daniel Jacobowitz 0 siblings, 0 replies; 17+ messages in thread From: Daniel Jacobowitz @ 2006-08-29 21:17 UTC (permalink / raw) To: Steve Eaton; +Cc: Mark Kettenis, dits365, gdb 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 20:12 ` Daniel Jacobowitz 2006-08-29 21:05 ` Steve Eaton @ 2006-08-29 21:08 ` Mark Kettenis 2006-08-29 21:24 ` Daniel Jacobowitz 2006-08-30 5:22 ` chen free 2 siblings, 1 reply; 17+ messages in thread From: Mark Kettenis @ 2006-08-29 21:08 UTC (permalink / raw) To: drow; +Cc: dits365, gdb > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 21:08 ` Mark Kettenis @ 2006-08-29 21:24 ` Daniel Jacobowitz 0 siblings, 0 replies; 17+ messages in thread From: Daniel Jacobowitz @ 2006-08-29 21:24 UTC (permalink / raw) To: Mark Kettenis; +Cc: dits365, gdb 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 20:12 ` Daniel Jacobowitz 2006-08-29 21:05 ` Steve Eaton 2006-08-29 21:08 ` Mark Kettenis @ 2006-08-30 5:22 ` chen free 2006-08-30 12:39 ` Daniel Jacobowitz 2 siblings, 1 reply; 17+ messages in thread From: chen free @ 2006-08-30 5:22 UTC (permalink / raw) To: Mark Kettenis, gdb 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-30 5:22 ` chen free @ 2006-08-30 12:39 ` Daniel Jacobowitz 2006-08-30 13:24 ` chen free 0 siblings, 1 reply; 17+ messages in thread From: Daniel Jacobowitz @ 2006-08-30 12:39 UTC (permalink / raw) To: chen free; +Cc: Mark Kettenis, gdb 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-30 12:39 ` Daniel Jacobowitz @ 2006-08-30 13:24 ` chen free 0 siblings, 0 replies; 17+ messages in thread From: chen free @ 2006-08-30 13:24 UTC (permalink / raw) To: Daniel Jacobowitz, Mark Kettenis, gdb 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 12:03 What exactly does "info sharedlibrary" command show? chen free 2006-08-29 12:40 ` Daniel Jacobowitz @ 2006-08-29 12:47 ` Frederic RISS 2006-08-29 13:00 ` chen free 1 sibling, 1 reply; 17+ messages in thread From: Frederic RISS @ 2006-08-29 12:47 UTC (permalink / raw) To: chen free; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 12:47 ` Frederic RISS @ 2006-08-29 13:00 ` chen free 2006-08-29 13:20 ` Frederic RISS 0 siblings, 1 reply; 17+ messages in thread From: chen free @ 2006-08-29 13:00 UTC (permalink / raw) To: Frederic RISS; +Cc: gdb 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. > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 13:00 ` chen free @ 2006-08-29 13:20 ` Frederic RISS 2006-08-29 13:36 ` chen free 0 siblings, 1 reply; 17+ messages in thread From: Frederic RISS @ 2006-08-29 13:20 UTC (permalink / raw) To: chen free; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What exactly does "info sharedlibrary" command show? 2006-08-29 13:20 ` Frederic RISS @ 2006-08-29 13:36 ` chen free 0 siblings, 0 replies; 17+ messages in thread From: chen free @ 2006-08-29 13:36 UTC (permalink / raw) To: Frederic RISS; +Cc: gdb 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. > > ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2006-08-30 13:24 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-08-29 12:03 What exactly does "info sharedlibrary" command show? chen free 2006-08-29 12:40 ` Daniel Jacobowitz 2006-08-29 19:15 ` Mark Kettenis 2006-08-29 19:28 ` Daniel Jacobowitz 2006-08-29 20:06 ` Mark Kettenis 2006-08-29 20:12 ` Daniel Jacobowitz 2006-08-29 21:05 ` Steve Eaton 2006-08-29 21:17 ` Daniel Jacobowitz 2006-08-29 21:08 ` Mark Kettenis 2006-08-29 21:24 ` Daniel Jacobowitz 2006-08-30 5:22 ` chen free 2006-08-30 12:39 ` Daniel Jacobowitz 2006-08-30 13:24 ` chen free 2006-08-29 12:47 ` Frederic RISS 2006-08-29 13:00 ` chen free 2006-08-29 13:20 ` Frederic RISS 2006-08-29 13:36 ` chen free
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox