Shared library mappings in /proc/pid/maps

Question

Why does /proc/pid/maps contain a few records for the same library ? Here is an example:

7fae7db9f000-7fae7dc8f000 r-xp 00000000 08:05 536861                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20
7fae7dc8f000-7fae7de8f000 ---p 000f0000 08:05 536861                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20
7fae7de8f000-7fae7de97000 r--p 000f0000 08:05 536861                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20
7fae7de97000-7fae7de99000 rw-p 000f8000 08:05 536861                     /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20

What does this mean ?

Solution

The four records have different permissions, so they can't be merged.

• The r-xp entry describes a block of executable memory (x permission flag). That's the code.
• The r--p entry describes a block of memory that is only readable (r permission flag). That's static data (constants).
• The rw-p entry describes a block of memory that is writable (w permission flag). This is for global variables of the library.
• The ---p entry describes a chunk of address space that doesn't have any permissions (or any memory mapped to it).

All are private (p flag), meaning that if a process modifies a page (which is only possible for the writable part), that page will be copied (copy-on-write), and other processes will not see any change.

That last entry is a gap between the code segment and the data segment that's explicitly inserted by the GNU linker under certain circumstances. The purpose of this gap is to ensure that the code (shareable between processes that use the same library) and the writable data (not shareable) are never in the same page. The size of the gap is 2MB because that's the largest page size¹ that Linux uses on your architecture (amd64). See What is the purpose of seemingly unusable memory mappings in linux? for more details.

¹ _{Most pages are 4kB, which is the “normal” page size. But there can be pages that use fewer MMU indirections, which is slightly faster but wastes a lot of space unless the application actually uses very large blocks of memory. Linux calls these huge pages.}

Source and more information for the unmapped gap: Why does gnome-panel use 290MB? by RJK. See also the entry for /proc/PID/maps in the Linux kernel documentation, Understanding Linux /proc/id/maps and /proc/$pid/maps shows pages with no rwx permissions on x86_64 linux on Stack Overflow.

Comments

[Gilles 'SO- stop being evil']

@陳力 A .rodata section would have r--p flags, yes.

[Ravi A]

The shared libraries are used by multiple applications, as per my knowledge shared library will be loaded into memory once and shared by different processes. How multiple processes will be accessed shared library, specific to the "rw-p" section? Multiple processes can perform write in this section.

[Gilles 'SO- stop being evil']

@RaviA Only the unmodifiable parts of the shared library are shared. The rw-p section has one instance per process.

[Ravi A]

@Gilles'SO-stopbeingevil' Is it possible to see the actual address space of the library? My understanding is that each process that is using the shared library will map the processes address space to the library's address(for the unmodifiable parts:r-xp, r--p, ---p ), as the library will be loaded once in the system memory(RAM).

[Gilles 'SO- stop being evil']

@RaviA A library doesn't have an address space. Each process has one. Different processes don't have to map the library at the same address.

[Ravi A]

@Gilles'SO-stopbeingevil' So shared library will be loaded into system memory multiple times(for each process which required that shared library)?

[Gilles 'SO- stop being evil']

@RaviA No. Each process has its own mapping even for the parts that are only loaded once. The same physical page can be mapped at different addresses in different processes. The mapping, i.e. the correspondence between virtual addresses and physical addresses, is a per-process attribute. The memory allocation, where parts of the library file are loaded into memory, is global.

[Ravi A]

@Gilles'SO-stopbeingevil' ld.so.cache will maintain the information of all the shared libraries that are currently loaded into system memory?

[Gilles 'SO- stop being evil']

@RaviA No, ld.so.cache has nothing to do with loading in memory. It's about mapping a file name to a path, i.e. finding which directory the library is in.