LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   What's the purpose of the extra virtual memory overhead for 64-bit libraries? (https://www.linuxquestions.org/questions/linux-software-2/what%27s-the-purpose-of-the-extra-virtual-memory-overhead-for-64-bit-libraries-680094/)

ddenisen 10-30-2008 03:46 PM
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.

Valery Reznic 10-31-2008 12:51 AM
Could you post output of
Code:
readelf -l /lib64/tls/libm-2.3.4.so
?

ddenisen 10-31-2008 08:59 AM
<Didn't use CODE tags around the output so the post was incomprehensible. Removed it>

ddenisen 10-31-2008 09:02 AM
That came out ugly. Let me try again:

Code:
> 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

Valery Reznic 11-05-2008 03:39 AM
Quote:
Originally Posted by ddenisen (Post 3327314)
That came out ugly. Let me try again:

Code:
> 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.


All times are GMT -5. The time now is 08:13 PM.