Description: When testing the glibc-master (2023-11-13) on sparc32 (leon) a memset regression was observed. The issue was introduced by commit a61933fe27df ("sparc: Remove bzero optimization"). How to reproduce: It can be reproduced running the "string/test-memset" test on sparc32. Fail rate: 100% Test output: string/test-memset.test-result: FAIL: string/test-memset original exit status 1 string/test-memset.out: Didn't expect signal from child: got `Segmentation fault' Root cause: The reason for the issue was that when moving the bzero routine to the end of the memset, the branch jump in the end made a jump back to wrong label causing the invalid data access. A fix has been implemented and will be submitted. -- glibc version: master d1dcb565a1fb (2023-11-13) - The issue was first observed in glibc-2.36. gcc version 10.2.0 (LEON Linux 5.10 Toolchain 1.4-87-gcd8128e) - sparc-gaisler-linux5.10 GNU ld (GNU Binutils) 2.34 glibc configure options: --prefix=/usr --enable-bind-now --host=sparc-gaisler-linux5.10 --with-headers=$USER/git/linux-toolchain/build-gcc-linux64//opt/sparc-gaisler-linux5.10/sysroot/usr/include --with-binutils=$USER/git/linux-toolchain/build-gcc-linux64/binutils/binutils --disable-default-pie libc_cv_forced_unwind=yes libc_cv_ssp=no Target: Linux buildroot 5.10.175-leon1.4 Host: Ubuntu 22.04 6.2.0-36-generic
Fixed on 2.39.
Just FYI the commit that fixed this was: https://sourceware.org/git/?p=glibc.git;a=commit;h=578190b7e43305141512dee777e4a3b3e8159393 And it was broken for the following releases: glibc-2.36 glibc-2.37 glibc-2.38
(In reply to Adhemerval Zanella from comment #1) > Fixed on 2.39. Does this by any chance need to be fixed on sparc64 as well? This bug could be the reason for the posix_spawn() bug we're seeing on sparc64.
(In reply to John Paul Adrian Glaubitz from comment #3) > (In reply to Adhemerval Zanella from comment #1) > > Fixed on 2.39. > > Does this by any chance need to be fixed on sparc64 as well? > > This bug could be the reason for the posix_spawn() bug we're seeing on > sparc64. The sparc64 changes were less intrusive and I could not see any change that might trigger it. The niagara4 changes slight the alignment of the 'clr' instruction: diff --git a/sysdeps/sparc/sparc64/multiarch/memset-niagara4.S b/sysdeps/sparc/sparc64/multiarch/memset-niagara4.S index 1ccf24e516..d6fbd83009 100644 --- a/sysdeps/sparc/sparc64/multiarch/memset-niagara4.S +++ b/sysdeps/sparc/sparc64/multiarch/memset-niagara4.S @@ -39,10 +39,6 @@ ENTRY(__memset_niagara4) sllx %o2, 32, %g1 ba,pt %icc, 1f or %g1, %o2, %o4 -END(__memset_niagara4) - - .align 32 -ENTRY(__bzero_niagara4) clr %o4 1: cmp %o1, 16 ble %icc, .Ltiny @@ -118,6 +114,6 @@ ENTRY(__bzero_niagara4) bne,pt %icc, 1b add %o0, 0x30, %o0 ba,a,pt %icc, .Lpostloop -END(__bzero_niagara4) +END(__memset_niagara4) #endif But afaiu this should not change the correctness of the code. Also, unless you are building with --disable-multi-arch; sparc64 string tests will check for every string implementation currently supported by the CPU. So I would expect that a failure in memset would trigger at least one regression as for sparc32.