Re: lib/57628: multithread programs may deadlock in ld.elf_so (sparc on sparc64)

[Martin Husemann <martin%duskware.de@localhost>]

The following reply was made to PR lib/57628; it has been noted by GNATS.

From: Martin Husemann <martin%duskware.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/57628: multithread programs may deadlock in ld.elf_so (sparc
 on sparc64)
Date: Tue, 26 Sep 2023 20:29:45 +0200

 This may be due to missing setup of the atomic lock support stuff,
 as we have two copies in the binary:
 
  > gdb /usr/tests/dev/sysmon/t_swwdog 
 GNU gdb (GDB) 13.2
 Copyright (C) 2023 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.
 Type "show copying" and "show warranty" for details.
 This GDB was configured as "sparc--netbsdelf".
 Type "show configuration" for configuration details.
 For bug reporting instructions, please see:
 <https://www.gnu.org/software/gdb/bugs/>.
 Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.
 
 For help, type "help".
 Type "apropos word" to search for commands related to "word"...
 Reading symbols from /usr/tests/dev/sysmon/t_swwdog...
 Reading symbols from /usr/libdata/debug//usr/tests/dev/sysmon/t_swwdog.debug...
 (gdb) break __libc_atomic_init
 Function "__libc_atomic_init" not defined.
 Make breakpoint pending on future shared library load? (y or [n]) y
 Breakpoint 1 (__libc_atomic_init) pending.
 (gdb) run disarm
 Starting program: /usr/tests/dev/sysmon/t_swwdog disarm
 
 Breakpoint 1.2, __libc_atomic_init ()
     at /work/src/lib/libc/../../common/lib/libc/atomic/atomic_init_testset.c:281
 281     /work/src/lib/libc/../../common/lib/libc/atomic/atomic_init_testset.c: No such file or directory.
 (gdb) info break
 Num     Type           Disp Enb Address    What
 1       breakpoint     keep y   <MULTIPLE> 
         breakpoint already hit 1 time
 1.1                         y   0x25ddded4 in __libc_atomic_init 
                                            at /work/src/lib/libc/../../common/lib/libc/atomic/atomic_init_testset.c:281
 1.2                         y   0x3ec301d4 in __libc_atomic_init 
                                            at /work/src/lib/libc/../../common/lib/libc/atomic/atomic_init_testset.c:281
 (gdb) info dll
 From        To          Syms Read   Shared Object Library
 0x25dd0ec8  0x25dde050  Yes         /usr/libexec/ld.elf_so
 0x3e784b0c  0x3e78e058  Yes         /usr/lib/librumpdev_sysmon.so.0
 0x3e7b2454  0x3e7b4e00  Yes         /usr/lib/librumpdev.so.0
 0x3e7e90c8  0x3e83ab64  Yes         /usr/lib/librumpvfs.so.0
 0x3e870640  0x3e8707b8  Yes         /usr/lib/librumpvfs_nofifofs.so.0
 0x3e8c5298  0x3e974b98  Yes         /usr/lib/librump.so.0
 0x3e9e2f38  0x3e9e91e8  Yes         /usr/lib/librumpuser.so.0
 0x3ea15600  0x3ea1ea20  Yes         /usr/lib/libpthread.so.1
 0x3ea44b24  0x3ea4ea20  Yes         /usr/lib/libatf-c.so.0
 0x3ea70378  0x3ea70580  Yes (*)     /usr/lib/libsparc_v8.so.0
 0x3eacce10  0x3ec30404  Yes         /usr/lib/libc.so.12
 0x3ecb195c  0x3ecba99c  Yes         /usr/lib/libgcc_s.so.1
 
 
 ... so one version of __libc_atomic_init in ld.elf_so itself, and one
 in libc. The libc one gets it's __libc_atomic_init function called,
 but the ld.elf_so one apparently never.
 
 Which probably means that we are trying to use RAS to emulate the atomic
 operations, on a multiprocessor machine - which is doomed.