[Bug nptl/26566] New: nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[Bug nptl/26566] New: nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[msc at linux dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

            Bug ID: 26566
           Summary: nptl/tst-thread-exit-clobber fails on
                    powerpc/powerpc64 with GCC 10.2
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: msc at linux dot ibm.com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

FAIL: nptl/tst-thread-exit-clobber
original exit status 1
info: unsigned int, direct pthread_exit call
error: tst-thread-exit-clobber.cc:125: not true: value ==
magic_values_double.v4
error: tst-thread-exit-clobber.cc:122: not true: value ==
magic_values_double.v3
error: tst-thread-exit-clobber.cc:119: not true: value ==
magic_values_double.v2
error: tst-thread-exit-clobber.cc:116: not true: value ==
magic_values_double.v1
error: tst-thread-exit-clobber.cc:113: not true: value ==
magic_values_double.v0
error: 5 test failures

I can only reproduce this error on ppc and ppc64, not ppc64le. Also, it works
with GCC 9.3, but fails with GCC 10.2

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
I can't reproduce it with gcc-10 from the build-many-glibcs.py on the gccfarm
gcc203.  I also tried with -fstack-clash-protection (as indicated by the test
itself where it was added due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83641) but it also work as
expected.

In any case, this seems most likely a compiler or libgcc issue, could you check
if it is the case?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[tuliom at ascii dot art.br]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

Tulio Magno Quites Machado Filho <tuliom at ascii dot art.br> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tuliom at ascii dot art.br

--- Comment #2 from Tulio Magno Quites Machado Filho <tuliom at ascii dot art.br> ---
(In reply to Adhemerval Zanella from comment #1)
> I can't reproduce it with gcc-10 from the build-many-glibcs.py on the
> gccfarm gcc203.

I reproduced on gcc203 with a normal build using:
configure --prefix=/usr --with-cpu=power8 CC=gcc-10 CXX=g++-10

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-01-22
                 CC|                            |carlos at redhat dot com
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
This came up again when reviewing the test results for glibc 2.39.

The problem is still present.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[mmatti at linux dot vnet.ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

Manjunath S Matti <mmatti at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bergner at linux dot ibm.com,
                   |                            |mmatti at linux dot vnet.ibm.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[mmatti at linux dot vnet.ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

--- Comment #4 from Manjunath S Matti <mmatti at linux dot vnet.ibm.com> ---
I observe this failure even with gcc version 13.2.0, but only when glibc is
configured with either --with-cpu=power8 or --with-cpu=power9. But when I
simply configure glibc without mention of any specific Architecture like 

../glibc/configure --enable-debug --prefix=/usr then I am unable to reproduce
this failure.

I suspect that the code generated is causing the issue

107 void
108 check_magic (int index, double value)
109 {
110   switch (index)
111     {
112     case 0:
113       TEST_VERIFY (value == magic_values_double.v0);

Assembly :

  5d4:  7c 69 1b 78     mr      r9,r3
- 5d8:  7f 64 db 78     mr      r4,r27
+ 5d8:  7b 64 00 20     clrldi  r4,r27,32 -->generating this code fixes the
issue
  5dc:  38 60 ff ff     li      r3,-1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[mmatti at linux dot vnet.ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

--- Comment #5 from Manjunath S Matti <mmatti at linux dot vnet.ibm.com> ---
I have some more info here:

I have run make check on both x86 and PPC64le, this particular testcase is
marked as
UNSUPPORTED: nptl/tst-thread-exit-clobber


Also this testcase compares 2 doubles is this ok ?

106 __attribute__ ((noinline, noclone, weak))
107 void
108 check_magic (int index, double value)
109 {
110   switch (index)
111     {
112     case 0:
113       TEST_VERIFY (value == magic_values_double.v0); -> here
114       break;

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[mmatti at linux dot vnet.ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

Manjunath S Matti <mmatti at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeevitha at linux dot ibm.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Manjunath S Matti from comment #5)
> I have some more info here:
> 
> I have run make check on both x86 and PPC64le, this particular testcase is
> marked as
> UNSUPPORTED: nptl/tst-thread-exit-clobber

I think this happens because it's a C++ tested, and you either do not have a
g++ installed, or libstdc++-static is missing (yes, we should probably fixed
that, and not disable all C++ tests if C++ static linking is unsupported).

> Also this testcase compares 2 doubles is this ok ?
> 
> 106 __attribute__ ((noinline, noclone, weak))
> 107 void
> 108 check_magic (int index, double value)
> 109 {
> 110   switch (index)
> 111     {
> 112     case 0:
> 113       TEST_VERIFY (value == magic_values_double.v0); -> here
> 114       break;

Are you asking because of a general rule that says not to compare floating
point numbers for equality? In this case, we want to make sure that the test
case preserves the bit pattern exactly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[jeevitha at linux dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

--- Comment #7 from Jeevitha P. <jeevitha at linux dot ibm.com> ---
This test case fails with glibc built using the following configuration:

configure --enable-debug --with-cpu=power8 --prefix=/usr

High-Level Information:

The issue lies in the callee-saved registers, which are not properly restored
by `__unwind_resume` from `libgcc_s.so.1`.

Test Case Flow:[Skipped integer cases since we don't have issues there]

In this test case, the `threadfunc` function calls `call_pthread_exit` under
certain conditions, which eventually calls `pthread_exit`.

 1. A thread is created and it calls `threadfunc` with an initial structure
containing five values.
 2. In threadfunc, the `checker` constructor is called five times to set those
initial values.
 3. Based on a condition, either `call_pthread_exit` or `pthread_exit` is
called. The failure occurs when `call_pthread_exit` is called.
 4. `call_pthread_exit` creates a new structure with five new values and passes
it to `call_pthread_exit_1` where  the `checker` is constructor called again
five more times with these new values. 
 5. `pthread_exit` is then called, which tries to destroy the objects created
by this thread. Since the thread called the `checker` constructor ten times, it
will call the corresponding destructor ten times to destroy them:
       First, it destroys the five objects in call_pthread_exit_1.
       Then, it destroys the five objects in threadfunc.
 6. The destructors check that the values passed during the function calls
matches the original struct values.

Assembly Perspective:

 1. In `threadfunc`, the structure values are stored in vector registers
(vs59-vs63) during the constructor calls.
 2. When `call_pthread_exit_1` is called, the callee-saved registers (v27-v31),
which overlap with (vs59-vs63), are saved in the stack. Then the same registers
(vs59-vs63) are then used to load the new structure values during the
constructor calls in `call_pthread_exit_1`.
 4. After that, `pthread_exit` is called, which invokes the destructor. 
 5. After all destructors are called in `call_pthread_exit_1`,
`__unwind_resume` is called to unwind the stack to restore the callee-saved
registers. However, `__unwind_resume` does not restore the vector registers, so
they do not have the original values which was set in `threadfunc`.
 6. When the destructors for the checker objects in `threadfunc` are called,
the values are overridden because of the same register usage in
`call_pthread_exit_1`. The checker destructor fails because the values do not
match.


If we disable vector instruction generation using -mno-vsx for the test case,
the issue does not occur. This is because the floating point registers, used
instead of vector registers, which are properly restored after the destructor
in `__unwind_resume`.


Backtrace for `_Unwind_resume` call from glibc,

gdb) bt
#2  0x00007ffff7b7132c in ._Unwind_Resume () from
/lib/powerpc64-linux-gnu/libgcc_s.so.1
#3  0x00007ffff7f324c4 in ?? ()//call_pthread_exit_1
#4  0x00007ffff7f32558 in ?? ()
#5  0x00007ffff7f325e4 in ?? ()
#6  0x00007ffff79bc958 in start_thread (arg=0x7ffff784f100) at
pthread_create.c:447
#7  0x00007ffff7a55dcc in .LY__clone3 () at
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone3.S:114

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

--- Comment #8 from Florian Weimer <fweimer at redhat dot com> ---
I suspect this happens if the libgcc unwinder has been built in such a way that
it doesn't require a CPU with VSX support. In that case, it's not safe to build
code with -mcpu=power8 if it catches exceptions, as the test shows.

I really don't think this is a glibc bug. The libgcc unwinder should have
conditional vector register processing even if built with -mno-vsx.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[jskumari at linux dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

Surya Kumari J <jskumari at linux dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jskumari at linux dot ibm.com

--- Comment #9 from Surya Kumari J <jskumari at linux dot ibm.com> ---
Adding some more details:

  In this testcase, we have the following call chain:
threadfunc()->call_pthread_exit()->call_pthread_exit1()->pthread_exit()

  The threadfunc() function is passed a struct containing 5 values. 5 local
objects of type “class checker” are created in threadfunc() and the instance
variable in each object is initialized with a value from the struct passed as
parameter. The values in the struct are stored in vector registers vs59-vs63
during the constructor calls.

  The call_pthread_exit1() routine too is passed a struct containing 5 values
(these values are different from those in the struct passed to threadfunc()).
The prolog in this routine stores the registers v27-v31 as these are
non-volatile registers. Note that v27-v31 overlap with vs59-vs63. This routine
creates 5 local objects of type ‘class checker’. The instance variable in each
object is initialized with a value from the struct passed as parameter. The
values in the struct are stored in vector registers vs59-vs63 during the
constructor calls.

  The destructor for ‘class checker’ has ‘inline’ attribute and hence we have
code to destroy the objects inlined into threadfunc() and call_pthread_exit1().
4. The destructor checks if the instance variable in the object is the same as
what it was initialized to, and the test fails if the value is not the same.
Since the destructor code is inlined, the value of the instance variable is
compared with the value in the vector register.

  While the checks in the destructors pass in call_pthread_exit1(), the checks
fail in threadfunc(). In threadfunc(), the vector registers do not contain the
expected values.

The assembly code for call_pthread_exit1 looks as follows:

call_pthread_exit1() {
     prolog code (contains code to save non-volatile vector registers)
     code to copy values from ‘struct parameter’ to vector registers
     code to call constructors
     call to pthread_exit()
  landing pad:
     inlined destructor code which reads vector registers
     call to _Unwind_Resume()
}

Assembly code for threadfunc():

threadfunc() {
     code to copy values from ‘struct parameter’ to vector registers
     code to call constructors
  landing pad:
     inlined destructor code which reads vector registers
}

  Pthread_exit() has to destroy all the objects created in the call chain. So
the landing pad code in call_pthread_exit1() is executed to destroy the objects
created in call_pthread_exit1(). After the destructors finish executing,
_Unwind_Resume is called because we have to unwind the stack.

  When the stack is unwound and we reach the landing pad in threadfunc(), the
vector registers no longer contain the correct values.  This is because the
vector registers have been rewritten in call_pthread_exit1(). Of course,
call_pthread_exit1()’s prolog saves these registers on stack before writing to
them. When we unwind and go from call_pthread_exit1()’s frame to the previous
frame (call_pthread_exit()), these vector registers have to be restored to
their original values from the stack.

  The issue can either be in unwinding (unwind is not restoring vector
registers correctly when unwinding the stack frames) or in gcc (gcc does not
produce correct unwind info thereby leading to incorrect unwinding) .

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/26566] nptl/tst-thread-exit-clobber fails on powerpc/powerpc64 with GCC 10.2

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26566

--- Comment #10 from Florian Weimer <fweimer at redhat dot com> ---
Please check the disassembly of _Unwind_RaiseException in libgcc_s.so.1 to
check whether it contains code to save vector registers, perhaps like this:

gdb -batch -ex "disassemble/s _Unwind_RaiseException" /lib64/libgcc_s.so.1

If GCC defaults to POWER8 instructions, it looks like this:

Dump of assembler code for function _Unwind_RaiseException:
../../../libgcc/unwind.inc:
87      {
   0x000000000000c610 <+0>:     addis   r2,r12,3
   0x000000000000c614 <+4>:     addi    r2,r2,-18704
   0x000000000000c618 <+8>:     mr      r0,r1
   0x000000000000c61c <+12>:    stdu    r1,-4096(r1)
   0x000000000000c620 <+16>:    stdu    r0,-528(r1)
   0x000000000000c624 <+20>:    mflr    r0
   0x000000000000c628 <+24>:    stfd    f14,4480(r1)
   0x000000000000c62c <+28>:    stfd    f15,4488(r1)
   0x000000000000c630 <+32>:    stfd    f16,4496(r1)
   0x000000000000c634 <+36>:    stfd    f17,4504(r1)
   0x000000000000c638 <+40>:    stfd    f18,4512(r1)
[…]
   0x000000000000c6cc <+188>:   beq     0xc6d4 <_Unwind_RaiseException+196>
   0x000000000000c6d0 <+192>:   std     r2,4648(r1)

88        struct _Unwind_Context this_context, cur_context;
89        _Unwind_Reason_Code code;
90        unsigned long frames;
91      
92        /* Set up this_context to describe the current stack frame.  */
93        uw_init_context (&this_context);
   0x000000000000c6d4 <+196>:   mfcr    r0
   0x000000000000c6d8 <+200>:   mflr    r5
   0x000000000000c6dc <+204>:   addi    r27,r1,3000
   0x000000000000c6e0 <+208>:   addi    r4,r1,4624
   0x000000000000c6e4 <+212>:   mr      r28,r3
   0x000000000000c6e8 <+216>:   mr      r3,r27
   0x000000000000c6ec <+220>:   addi    r30,r1,1920
   0x000000000000c6f0 <+224>:   addi    r29,r1,32
   0x000000000000c6f4 <+228>:   stw     r0,4088(r1)
   0x000000000000c6f8 <+232>:   stw     r0,4096(r1)
   0x000000000000c6fc <+236>:   stw     r0,4104(r1)
   0x000000000000c700 <+240>:   li      r0,4144
   0x000000000000c704 <+244>:   stvx    v20,r1,r0
   0x000000000000c708 <+248>:   li      r0,4160
   0x000000000000c70c <+252>:   stvx    v21,r1,r0
[…]

-- 
You are receiving this mail because:
You are on the CC list for the bug.