Re: Suspected bug in wait syscall or similar

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 30/03/2020 07:18, John Paul Adrian Glaubitz wrote:
> Hi Rolf!
> 
> On 3/30/20 10:41 AM, Rolf Eike Beer wrote:
>> I run a 32 bit Gentoo userspace on my T5120 with a 64 bit kernel (5.5.7 at the 
>> moment). This is nothing really new, I see this for a while, but it seems to 
>> got a bit worse lately.
> 
> Debian's glibc maintainer told me that the glibc testsuite on SPARC has more failures
> on 32-bit than on 64-bit. Maybe we should look into trying to get some of these failures
> fixed first. CC'ing Adhemerval from glibc upstream who has done a lot of bug fixing
> on SPARC in glibc.

I have been seeing some sparc32 issues on 64-bit kernels as well. I have
documented some on glibc release wiki [1].  I noted the wait and nanosleep
issue on 2.31 and after the changes required for y2038 safeness and some
refactoring in syscall handling on master branch I didn't see them anymore.
So I am not sure if they are related to kernel, code generation or glibc
itself.

The sparc32 master still show some issues:

FAIL: nptl/tst-cancel24-static
FAIL: nptl/tst-cancelx20
FAIL: nptl/tst-cancelx21
FAIL: nptl/tst-cond8-static
FAIL: nptl/tst-mutex8-static
FAIL: nptl/tst-mutexpi8-static

> 
> It could be useful in this context if Gentoo could provide a small Gentoo SPARC LDOM
> running 32-bit userland for the GCC Compile Farm. This way upstream developers get
> easy access to a Gentoo SPARC instance to be able to reproduce issues like this.
> 
>> When I read about https://sourceware.org/git/?
>> p=glibc.git;a=commit;h³3e946fbb1659d2c5937c4dd756a7c49a132dff I thought that 
>> this may solve the issue, but I rebuild my glibc in a chroot with that patch 
>> and at least the fish testsuite hangs are unchanged.
>>
>> Has anyone a clue what's going on there?

Funny thing about b33e946fbb1659d2c5937c4dd756a7c49a132dff is the original code
has been working for age (in fact since the port has been included), meaning
that gcc used to *not* generate a stack frame for:

static void
__rt_sigreturn_stub (void)
{
  __asm__ ("mov %0, %%g1\n\t"
	   "ta	0x6d\n\t"
	   : /* no outputs */
	   : "i" (__NR_rt_sigreturn));
}

static void
__sigreturn_stub (void)
{
  __asm__ ("mov %0, %%g1\n\t"
	   "ta	0x6d\n\t"
	   : /* no outputs */
	   : "i" (__NR_sigreturn));
}

The only recent change prior the move to assembly was on 2.25 where we had
to disable the stack protector.  For 2.31 release, for instance, I used the
gcc 7.5.0 since it didn't trigger this issue.

> I know that there have been some stability issues with the Linux kernel on SPARC
> with older hardware like the UltraSPARC IIIi. The T5120 we have and newer machines
> seem to run relatively fine with a 64-bit userland.

Not only stability issues, but I noticed that kernel developers had 
fixed a SysV IPC kernel issue on 32-bits kernels that has been 
lingering for years.  So I am not sure how well maintained is
32-bit sparc is in general.

[1] https://sourceware.org/glibc/wiki/Release/2.31