Newer hwcap failures

[Adhemerval Zanella]

On 28/01/2021 17:30, Adhemerval Zanella wrote:
> 
> 
> On 28/01/2021 17:21, Adhemerval Zanella wrote:
>>
>>
>> On 28/01/2021 17:01, Adhemerval Zanella wrote:
>>>
>>>
>>> On 28/01/2021 16:53, Florian Weimer wrote:
>>>> * Adhemerval Zanella:
>>>>
>>>>> Debugging the tst-ldconfig-ld_so_conf-update it seems that for some
>>>>> reason ldconfig is not updating the search path. Modifying the testcase
>>>>> to print the dlerror:
>>>>>
>>>>> dlopen (libldconfig-ld-mod.so): libldconfig-ld-mod.so: cannot open shared object file: No such file or directory
>>>>>
>>>>> I am trying to run strace on the container environment, but it seems
>>>>> that it gets confused (it triggers a failure in the rename call).
>>>>>
>>>>> Any idea?
>>>>
>>>> Do you use any special compiler flags?  We have a report of ISA level
>>>> property notes showing up unexpectedly:
>>>>
>>>>   <https://sourceware.org/pipermail/libc-help/2021-January/005648.html>
>>>>
>>>> I don't think this test has been adjusted to this new feature, it will
>>>> only work if the objects have no markup.
>>>
>>> This is failing on powerpc32 as well with the same error, so I am not sure
>>> this is really related to the ISA level property notes.
>>
>> The libldconfig-ld-mod.so is indeed listed on the cache, as indicated by
>> a 'ldconfig -p' after the final 'ldconfig' onelf/tst-ldconfig-ld_so_conf-update.c:
>>
>> 37 libs found in cache `/etc/ld.so.cache'
>>         libutil.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libutil.so.1
>>         libutil.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libutil.so
>>         libthread_db.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libthread_db.so.1
>>         libthread_db.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libthread_db.so
>>         librt.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/librt.so.1
>>         librt.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/librt.so
>>         libresolv.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libresolv.so.2
>>         libresolv.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libresolv.so
>>         libpthread.so.0 (libc6, OS ABI: Linux 3.2.0) => /lib/libpthread.so.0
>>         libpthread.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libpthread.so
>>         libpcprofile.so (libc6, OS ABI: Linux 3.2.0) => /lib/libpcprofile.so
>>         libnss_hesiod.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_hesiod.so.2
>>         libnss_hesiod.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_hesiod.so
>>         libnss_files.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_files.so.2
>>         libnss_files.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_files.so
>>         libnss_dns.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_dns.so.2
>>         libnss_dns.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_dns.so
>>         libnss_db.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_db.so.2
>>         libnss_db.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_db.so
>>         libnss_compat.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_compat.so.2
>>         libnss_compat.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_compat.so
>>         libnsl.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libnsl.so.1
>>         libmemusage.so (libc6, OS ABI: Linux 3.2.0) => /lib/libmemusage.so
>>         libm.so.6 (libc6, OS ABI: Linux 3.2.0) => /lib/libm.so.6
>>         libm.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libm.so
>>         libldconfig-ld-mod.so (libc6, OS ABI: Linux 3.2.0) => /tmp/tst-ldconfig/libldconfig-ld-mod.so
>>         libdl.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libdl.so.2
>>         libdl.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libdl.so
>>         libcrypt.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libcrypt.so.1
>>         libcrypt.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libcrypt.so
>>         libc.so.6 (libc6, OS ABI: Linux 3.2.0) => /lib/libc.so.6
>>         libanl.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libanl.so.1
>>         libanl.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libanl.so
>>         libSegFault.so (libc6, OS ABI: Linux 3.2.0) => /lib/libSegFault.so
>>         libBrokenLocale.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libBrokenLocale.so.1
>>         libBrokenLocale.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libBrokenLocale.so
>>         ld-linux.so.2 (ELF) => /lib/ld-linux.so.2
>>
>> However the dlopen is not considering it on search path, as indicated by
>> LD_DEBUG=all just before the dlopen failure:
>>
>>          1:     file=libldconfig-ld-mod.so [0];  dynamically loaded by /xxx/i686-linux-gnu/elf/tst-ldconfig-ld_so_conf-update [0]
>>          1:     find library=libldconfig-ld-mod.so [0]; searching
>>          1:      search cache=/etc/ld.so.cache
>>          1:      search path=/lib:/usr/lib              (system search path)
>>          1:       trying file=/lib/libldconfig-ld-mod.so
>>          1:       trying file=/usr/lib/libldconfig-ld-mod.so
>>
>> I am not sure why yet.
> 
> From my testings, I am seeing this issue on hppa, powerpc32 hardfloat, i686, and armhf.

The issue is test-container is copying the ld.so.cache from system into
testroot and thus _dl_sysdep_read_whole_file does not fail.

For 32-bit builds, there is not ld.so.cache then _dl_sysdep_read_whole_file
fails and further ldconfig does not change the process map (since
_dl_load_cache_lookup won't reload the cache after an initial failure).

That's explain why I am seeing this only on system with default 64-bit
userland.  I don't know exactly why I haven't see this before, neither
if it were some testing regression added recently.