What's the purpose of the extra virtual memory overhead for 64-bit libraries?

I noticed that every 64-bit library reserves either 1 or 2 MB of virtual memory. Here's an example snipped of "pmap <pid>" output (the interesting line has permissions "-----"):

0000003341800000 532K r-x-- /lib64/tls/libm-2.3.4.so
0000003341885000 1020K ----- /lib64/tls/libm-2.3.4.so
0000003341984000 4K r---- /lib64/tls/libm-2.3.4.so
0000003341985000 4K rw--- /lib64/tls/libm-2.3.4.so

32-bit libraries do not have this overhead. This memory does not seem to be backed by physical RAM (VmRSS number in /proc/<pid>/status is too small to include these overheads) and hence doesn't seem to be a problem. I'm still curious what that extra space is for. Does anybody know?

In case this matters, I'm using CentOS 4.6 with kernel 2.6.9-67 on x86-64 CPU.


Thank you.

Could you post output of

readelf -l /lib64/tls/libm-2.3.4.so

?

<Didn't use CODE tags around the output so the post was incomprehensible. Removed it>

That came out ugly. Let me try again:

> readelf -l /lib64/tls/libm-2.3.4.so

Elf file type is DYN (Shared object file)
Entry point 0x3341803df0
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000003341800040 0x0000003341800040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000080570 0x0000003341880570 0x0000003341880570
                 0x000000000000001c 0x000000000000001c  R      10
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000003341800000 0x0000003341800000
                 0x000000000008459c 0x000000000008459c  R E    100000
  LOAD           0x0000000000084dc8 0x0000003341984dc8 0x0000003341984dc8
                 0x00000000000003b8 0x0000000000000400  RW     100000
  DYNAMIC        0x0000000000084df0 0x0000003341984df0 0x0000003341984df0
                 0x00000000000001b0 0x00000000000001b0  RW     8
  NOTE           0x0000000000000238 0x0000003341800238 0x0000003341800238
                 0x0000000000000020 0x0000000000000020  R      4
  GNU_EH_FRAME   0x000000000008058c 0x000000334188058c 0x000000334188058c
                 0x0000000000000dfc 0x0000000000000dfc  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     8
  GNU_RELRO      0x0000000000084dc8 0x0000003341984dc8 0x0000003341984dc8
                 0x0000000000000238 0x0000000000000238  R      1

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .interp .eh_frame_hdr .eh_frame
   03     .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag
   06     .eh_frame_hdr
   07
   08     .ctors .dtors .jcr .dynamic .got

Originally Posted by ddenisen That came out ugly. Let me try again: > readelf -l /lib64/tls/libm-2.3.4.so Elf file type is DYN (Shared object file) Entry point 0x3341803df0 There are 9 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0x0000003341800040 0x0000003341800040 0x00000000000001f8 0x00000000000001f8 R E 8 INTERP 0x0000000000080570 0x0000003341880570 0x0000003341880570 0x000000000000001c 0x000000000000001c R 10 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x0000000000000000 0x0000003341800000 0x0000003341800000 0x000000000008459c 0x000000000008459c R E 100000 LOAD 0x0000000000084dc8 0x0000003341984dc8 0x0000003341984dc8 0x00000000000003b8 0x0000000000000400 RW 100000 DYNAMIC 0x0000000000084df0 0x0000003341984df0 0x0000003341984df0 0x00000000000001b0 0x00000000000001b0 RW 8 NOTE 0x0000000000000238 0x0000003341800238 0x0000003341800238 0x0000000000000020 0x0000000000000020 R 4 GNU_EH_FRAME 0x000000000008058c 0x000000334188058c 0x000000334188058c 0x0000000000000dfc 0x0000000000000dfc R 4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 8 GNU_RELRO 0x0000000000084dc8 0x0000003341984dc8 0x0000003341984dc8 0x0000000000000238 0x0000000000000238 R 1 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .interp .eh_frame_hdr .eh_frame 03 .ctors .dtors .jcr .dynamic .got .got.plt .data .bss 04 .dynamic 05 .note.ABI-tag 06 .eh_frame_hdr 07 08 .ctors .dtors .jcr .dynamic .got

ld-linux working as following:
1) map ALL PT_LOAD segments at ONCE (with permission of first PT_LOAD segment)
2) walk PT_LOAD segment list and change (with mprotect) segment's permission to correct ones. That include changing 'hole' permissions to 0

PT_LOAD segments alignment on x86_64 is 0x100000. PAGE_SIZE is 0x1000
(Why alignment is 0x100000 is beyond me.)
When ld-linux decide where first segment ended it uses PAGE_SIZE. But when linker select virtual address for the second PT_LOAD segments it used alignment (i.e 0x100000) So from the loader's point of view there is a hole between first and second PT_LOAD segment, and you saw it as mapping with '---' permissions.

On the x86 both alignment and PAGE_SIZE are 0x1000 so there is no dummy mappings there.