ARC testsuite regressions (was Re: [PATCH v7.2 07/13] ARC: Linux Syscall Interface)
Vineet Gupta
Vineet.Gupta1 at synopsys.com
Fri Jul 10 16:07:23 EDT 2020
On 7/10/20 10:02 AM, Florian Weimer via Libc-alpha wrote:
> * Vineet Gupta via Libc-alpha:
>
>> 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.
>
> No, rebuilding glibc from scratch should be fine.
Right, I clean built the entire toolchain and that didn't help - but turned out to
be sane thing anyways as installed headers seems were not rebuilt/installed and I
needed the signum.h -> signum-arch.h fixup in vfork.S
>> 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
>
> This suggests to me that the static initialization code does not produce
> sufficient alignment for the TCB, given the 32-byte alignment required
> by the rseq area.
>
> You could try and see what happens if you change
> sysdeps/arc/nptl/pthreaddef.h to this:
>
> /* Alignment requirement for TCB. */
> #define TCB_ALIGNMENT 32
>
> If that helps, we have more of a generic issue here. 8-/
Bingo, that fixes all the dlfcn/* failures (full testsuite still running)
PASS: dlfcn/tststatic
PASS: dlfcn/tststatic2
PASS: dlfcn/tststatic3
PASS: dlfcn/tststatic4
PASS: dlfcn/tststatic5
So is that the fix or more is needed ?
> The problem is that the TLS memory allocator does not add alignment
> padding on its own. This could meet additional alignment requirements
> if there is just one thread yet when higher-aligned TLS is loaded.
>
>> Also while we figure this out, does this prevent ARC port from being
>> committed.
>
> I don't think so. We just have to make sure that it does not block the
> release, i.e. resolve this during the next week or two. Do you think
> that would that be possible?
So it makes sens to commit ARC port now and your fix along the lines can then say
what it fixed in-tree.
More information about the linux-snps-arc
mailing list