/proc//map shows more shared library than ldd for busybox

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.

Answer

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.

Advertisement

Answer