ARC testsuite regressions (was Re: [PATCH v7.2 07/13] ARC: Linux Syscall Interface)

[Vineet Gupta]

On 7/10/20 2:28 AM, Florian Weimer via Libc-alpha wrote:
> * Alistair Francis via Libc-alpha:
> 
>> On Thu, Jul 9, 2020 at 2:36 PM Vineet Gupta via Libc-alpha
>> <libc-alpha at sourceware.org> wrote:
>>>
>>> On 7/9/20 2:13 PM, Vineet Gupta via Libc-alpha wrote:
>>>>> Rebased ARC port on master and fired a build-many-glibcs <glibcs> now (expect some
>>>>> abilist updates). Will do a full testsuite run
>>>>
>>>> No regressions in sysvipc tests !
>>>
>>> But quite a few regressions. Baseline is ARC port off of upstream 81b1c8cbb5b4
>>> "(hurd: Simplify usleep timeout computation)" and failures below seen in ARC port
>>> off of today's master ffd178c651b8 "(sysv: linux: Add 64-bit time_t variant for
>>> shmctl)"
>>>
>>> FAIL: dlfcn/tststatic
>>> FAIL: dlfcn/tststatic2
>>> FAIL: dlfcn/tststatic3
>>> FAIL: dlfcn/tststatic4
>>> FAIL: dlfcn/tststatic5
>>> FAIL: elf/tst-libc_dlvsym
>>> FAIL: elf/tst-libc_dlvsym-static
>>> FAIL: elf/tst-single_threaded-static-dlopen
>>> FAIL: elf/tst-tls9-static
>>
>> I see the same recent-ish regressions for RV32.
> 
> Did you rebuild from scratch?  After the libc.so/ld.so ABI changes that
> went in recently, it could be the result of incomplete make
> dependencies.

From scratch meaning glibc alone or the whole toolchain. I used buildroot and
glibc-dirclean to nuke entire glibc but gcc was not rebuilt. I can try that too.

Some of the failed tests have prints about static TLS block ... so I'm wondering
if they could be related ?

| $ cat dlfcn/tststatic.out
| .../build/libc.so.6: cannot allocate memory in static TLS block

Also while we figure this out, does this prevent ARC port from being committed. It
is a functioning system otherwise: I'm doing doing cross run of testsuite with
sshd etc involved and these addition 10+ failures don't seem to be getting in the way.