0

Why /proc/<pid>/maps shows more shared library than ldd program?

Here's an example:

# ------------ Embedded Linux side ------------ # ps ..... 28 root [jffs2_gcd_mtd2] 132 root -/bin/sh ---> the target to show 155 root [kworker/0:2] # # Note: -/bin/sh is actually /bin/busybox # cat /proc/132/maps 00400000-004bc000 r-xp 00000000 1f:02 34 /bin/busybox 004cc000-004cd000 rw-p 000bc000 1f:02 34 /bin/busybox 004cd000-004ee000 rw-p 00000000 00:00 0 [heap] 775bb000-775cb000 rw-p 00000000 00:00 0 775cb000-775d6000 r-xp 00000000 1f:02 397 /lib/libnss_files-2.22.so 775d6000-775e5000 ---p 0000b000 1f:02 397 /lib/libnss_files-2.22.so 775e5000-775e6000 r--p 0000a000 1f:02 397 /lib/libnss_files-2.22.so 775e6000-775e7000 rw-p 0000b000 1f:02 397 /lib/libnss_files-2.22.so 775e7000-775ed000 rw-p 00000000 00:00 0 775ed000-7775a000 r-xp 00000000 1f:02 382 /lib/libc-2.22.so 7775a000-7776a000 ---p 0016d000 1f:02 382 /lib/libc-2.22.so 7776a000-7776d000 r--p 0016d000 1f:02 382 /lib/libc-2.22.so 7776d000-77770000 rw-p 00170000 1f:02 382 /lib/libc-2.22.so 77770000-77772000 rw-p 00000000 00:00 0 77772000-77795000 r-xp 00000000 1f:02 374 /lib/ld-2.22.so 777a1000-777a2000 rw-p 00000000 00:00 0 777a3000-777a4000 rw-p 00000000 00:00 0 777a4000-777a5000 r--p 00022000 1f:02 374 /lib/ld-2.22.so 777a5000-777a6000 rw-p 00023000 1f:02 374 /lib/ld-2.22.so 7fb42000-7fb63000 rwxp 00000000 00:00 0 [stack] 7fff7000-7fff8000 r-xp 00000000 00:00 0 [vdso] # cksum /bin/busybox 698740119 773496 /bin/busybox #---------- Then on the PC side ---------------- $ cksum ./busybox 698740119 773496 bin/busybox $ /usr/local/bin/mips-linux-gnu-ldd bin/busybox checking sub-depends for 'not found' libc.so.6 => not found (0x00000000) /lib/ld.so.1 => /lib/ld.so.1 (0x00000000)

cksum is used to check if the files are the same. From PC side ldd cross-tool, it shows busybox depends on libc and ld only. However, in the real run-time environment, /proc/132/maps shows one more shared library, /lib/libnss_files-2.22.so.

To confirm if we have indirect dependency:

$ /usr/local/bin/mips-linux-gnu-ldd lib/libc.so.6 /lib/ld.so.1 => /lib/ld.so.1 (0x00000000) $ /usr/local/bin/mips-linux-gnu-ldd lib/ld.so.1 not a dynamic executable

No. ldd show that libc depends on ld, which is already one of busybox's dependency.

Improve this question

2 Answers 2

Reset to default
1

One process can dlopen(3) a shared object and load it in its address space without the need of linking it to it. This means a shared object doesn't need to appear in the ldd(1) output for it to appear in the running instance of the program.

I'm not saying that this is the case, but you can develop shared objects with the only purpose of adding (unknown) functionality to a program that had open design to incorporate libraries on demand.

Normally, those programs don't appear in the ldd output.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

libnss_files is a component of libc. It's loaded on demand, and is used to perform name lookups in static files, like /etc/passwd and /etc/hosts. (There's also libnss_dns for DNS lookups.)

For more information, see the libc documentation for NSS (Name Service Switch).

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.