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()
On 10/24/19 8:08 AM, Florian Weimer wrote:
> * Carlos O'Donell:
>
>> On 10/20/19 5:37 PM, Lukasz Majewski wrote:
>>> On Fri, 18 Oct 2019 16:02:22 -0400
>>> Carlos O'Donell <carlos@redhat.com> wrote:
>>>
>>>> On 10/3/19 9:59 AM, Carlos O'Donell wrote:
>>>>> On 8/5/19 5:56 PM, Leandro Pereira wrote:
>>>>>> 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
>>>>>>
>>>>>> 2019-08-05 Leandro Pereira <leandro.pereira@microsoft.com>
>>>>>>
>>>>>> * elf/dl-load.c: Use __pread64_nocancel() instead of
>>>>>> __lseek()+ __read_nocancel().
>>>>>> * sysdeps/x86/dl-prop.h: Likewise.
>>>>>
>>>>> OK for master. I'll push after testing with bmg. No regressions on
>>>>> x86_64.
>>>>>
>>>>> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
>>>>
>>>> Pushed.
>>>>
>>>
>>> Unfortunately, I've found a regression on HURD when using
>>> build-many-glibcs.py (for testing some other code):
>>>
>>> ../glibc-many-build/src/glibc/libio/../sysdeps/posix/libc_fatal.c:161:
>>> multiple definition of `__libc_fatal';
>>> ../glibc-many-build/build/glibcs/i686-gnu/glibc/elf/dl-allobjs.os:/work/lukma/glibc/glibc-many-build/src/glibc/elf/dl-minimal.c\
>>> :188: first defined here
>>>
>>> To reproduce:
>>> ../src/scripts/build-many-glibcs.py
>>> <path>/glibc/glibc-many-build glibcs i686-gnu
>>>
>>> emacs logs/glibcs/i686-gnu/004-glibcs-i686-gnu-build-log.txt
>>
>> Thanks. I didn't see this. Let me start another build.
>
> I think I know what's going on and I'm looking to a fix.
>
> We shouldn't let such build regressions linger for so long.
Sorry, you are right 4 days is too long. It speaks again for pre-commit
CI since even straight forward things can have consequences like this.
I ran b-m-g and didn't see this, but perhaps I made a mistake. At least
twice I've botched the glibc branch checkout and tested b-m-g against
upstream instead of upstream+patch.
You and I have spoken about this off list and you have a patch, so I'm
going to leave this with you to fix while I go review the CodeSourcery/Mentor
patches.
--
Cheers,
Carlos.