2005-10-03 07:07:27

by Arijit Das

[permalink] [raw]
Subject: Shared Library Holes in x86_amd64

If I strace a "/bin/sleep 23" command in a RHAS3.0/x86-AMD64 machine, I
see that holes are being created in some of the mapped shared libraries
using the mprotect system call like this:

2a95931000 1260K r-xp /lib64/tls/libc-2.3.2.so
2a95a6c000 1024K ---p /lib64/tls/libc-2.3.2.so <HOLE>
2a95b6c000 20K rw-p /lib64/tls/libc-2.3.2.so

open("/lib64/tls/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\322\1\0"...,
640) = 640
fstat(3, {st_mode=S_IFREG|0755, st_size=1669064, ...}) = 0
mmap(NULL, 2375528, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x2a95931000
mprotect(0x2a95a6c000, 1085288, PROT_NONE) = 0
mmap(0x2a95b6c000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x13b000) = 0x2a95b6c000
mmap(0x2a95b71000, 16232, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2a95b71000
close(3)

This gives me a feeling that a section of the shared library file i.e.
the section mapped with PROT_NONE flag doesn't contain any useful data
and hence, is not being used.

Does anybody know the reason behind such holes inside a shared library
like /lib64/tls/libc.so.6 in RHAS30/x86_amd64 platforms?

Thanks for your time,
Arijit


2005-10-03 07:13:19

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Shared Library Holes in x86_amd64


>
> Does anybody know the reason behind such holes inside a shared library
> like /lib64/tls/libc.so.6 in RHAS30/x86_amd64 platforms?

the minimum alignment as specified in the x64 ABI is 1 Megabyte (this
was discussed last week already here after the first time you asked it,
and also is not a kernel thing so your questions are off-topic for this
mailing list). ld.so decides the easiest way to get that alignment is to
PROT_NONE it, also to make sure nothing can go "in the middle" of such a
library.