This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] elf: Use nocancel pread64() instead of lseek()+read()
- From: Yann Droneaud <ydroneaud at opteya dot com>
- To: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: Leandro Pereira <Leandro dot Pereira at microsoft dot com>
- Date: Thu, 03 Oct 2019 17:31:12 +0200
- Subject: Re: [PATCH 2/2] elf: Use nocancel pread64() instead of lseek()+read()
- References: <MWHPR2101MB073287753F9E8D211AF49DD3E8DA0@MWHPR2101MB0732.namprd21.prod.outlook.com>
Hi,
Le lundi 05 août 2019 à 21:56 +0000, Leandro Pereira a écrit :
> Transforms this, when linking in a shared object:
>
> openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> read(3, "\177ELF\2\1\1\3"..., 832) = 832
> lseek(3, 792, SEEK_SET) = 792
> read(3, "\4\0\0\0\24\0\0\0"..., 68) = 68
> fstat(3, {st_mode=S_IFREG|0755, st_size=6699224, ...}) = 0
> lseek(3, 792, SEEK_SET) = 792
> read(3, "\4\0\0\0\24\0\0\0"..., 68) = 68
> lseek(3, 864, SEEK_SET) = 864
> read(3, "\4\0\0\0\20\0\0\0"..., 32) = 32
>
> Into this:
>
> openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> read(3, "\177ELF\2\1\1\3"..., 832) = 832
> pread(3, "\4\0\0\0\24\0\0\0"..., 68, 792) = 68
> fstat(3, {st_mode=S_IFREG|0755, st_size=6699224, ...}) = 0
> pread(3, "\4\0\0\0\24\0\0\0"..., 68, 792) = 68
> pread(3, "\4\0\0\0\20\0\0\0"..., 32, 864) = 32
>
I confirm the behavior. And the usefulness of the patch.
Anyway I'm quite surprised ld.so is reading twice 68 bytes at the same
792 offset. Moreover, the first read already brought 28 bytes out of
68.
Could these read() be replaced by a call to mmap(), then using mremap()
to brought the shared object in memory after initial inspection ?
Regards.
--
Yann Droneaud
OPTEYA