Shared Library Holes in x86_amd64

[Arijit Das]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/