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

[Alistair Francis]

On Fri, Jul 10, 2020 at 8:55 AM Vineet Gupta via Libc-alpha
<libc-alpha at sourceware.org> wrote:
>
> 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.

That's the same with me. The toolchain wasn't rebuilt but glibc was
built from a clean directory. I am rebuilding now with a rebuilt
toolchain.

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

I see the same messages.

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

That's what I see as well.

>
> 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.

Good question!

Alistair