amd64 process sizes

Kostik Belousov kostikbel at
Wed Sep 5 09:11:02 PDT 2007

On Wed, Sep 05, 2007 at 07:50:49PM +1000, Peter Jeremy wrote:
> I've been comparing VSZ reported for similar processes on amd64 and
> i386 and found that amd64 processes report as vastly larger than I
> expected:
> i386  amd64
> 1476   3572  getty
> 6272  29184  xclock
> 4784  28020  xdm
> 6420  30000  xterm
> 3828   9444  sendmail
> I did some further digging into the procfs map for xterm and found
> that each of the amd64 shared objects has an additional mapping that
> is 255 or 256 pages.  Once you remove those mappings, the sizes are
> reasonably similar.  A typical set of mappings is:
> 0x800f60000 0x800fba000 61 0 0xffffff0027ac2540 r-x 36 18 0x0 COW NC vnode /usr/local/lib/
> 0x800fba000 0x800fbb000 1 0 0xffffff002765ed20 r-x 1 0 0x2180 COW NC vnode /usr/local/lib/
> 0x800fbb000 0x8010bb000 18 0 0xffffff0027ac2540 r-x 36 18 0x0 COW NC vnode /usr/local/lib/ [*]
> 0x8010bb000 0x8010cd000 18 0 0xffffff00274d2c40 rw- 1 0 0x2180 COW NC vnode /usr/local/lib/
> 0x28284000 0x282d7000 15 0 0xc360ad68 r-x 9 6 0x0 COW NC vnode /usr/local/lib/
> 0x282d7000 0x282d8000 0 0 0xc3a4b210 r-x 1 0 0x2180 COW NC vnode /usr/local/lib/
> 0x282d8000 0x282df000 3 0 0xc3aef39c rwx 1 0 0x2180 COW NC vnode /usr/local/lib/
> Could someone please explain the purpose of the mapping [*] and what
> system resources they occupy.

On my outdated RELENG_6, relevant part of the
	readelf -a /usr/local/lib/
output is

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x000000000005a4ad 0x000000000005a4ad  R E    100000
  LOAD           0x000000000005b000 0x000000000015b000 0x000000000015b000
                 0x0000000000011948 0x0000000000011ed0  RW     100000
  DYNAMIC        0x000000000006b718 0x000000000016b718 0x000000000016b718
                 0x00000000000001e0 0x00000000000001e0  RW     8

As you see, virtual address for second loadable section (rw, data+bss) is
0x000000000015b000 (+base). This seems to be due to the alignment that is

The ghost mapping you see is due to the rtld algorithm for mapping the elf
object, that reserves the address space by doing mmap() for full range
where the sections would be located, and then remaps actual segments on the
appropriate offsets. See libexec/rtld-elf/map_object.c::map_object().

The alignment itself seems to come from (or, at least, reflected there)
/usr/libdata/ldscripts/elf_x86_64_fbsd.x* files, see ALIGN calculation
for rw sections.

At the end, the cause seems to be the toolchain configuration, namely, ld.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-amd64 mailing list