NetBSD Problem Report #57312

From www@netbsd.org  Thu Mar 30 15:15:25 2023
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id B617C1A923C
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 30 Mar 2023 15:15:24 +0000 (UTC)
Message-Id: <20230330151523.31B5B1A923D@mollari.NetBSD.org>
Date: Thu, 30 Mar 2023 15:15:23 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: Missing atomic symbols generated by gcc
X-Send-Pr-Version: www-1.0

>Number:         57312
>Category:       lib
>Synopsis:       Missing atomic symbols generated by gcc
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 30 15:20:00 +0000 2023
>Last-Modified:  Mon Apr 03 08:15:01 +0000 2023
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The NetBSD Foundation_explicit(memory_order_acq_rel)
>Environment:
brittle when cooked
>Description:
libc is missing many of the __atomic_* symbols that gcc generates references to for certain out-of-line cases of the C11 stdatomic.h API.

Cases where symbols are missing:

- On architectures that don't natively have CAS, like sparc, hppa, and early mips.
- For objects of unnaturally large sizes, for which atomic_is_lock_free is false and locking is required.
- When the -fno-inline-atomics flag is passed.

We probably need to define all the symbols listed here:
https://gcc.gnu.org/wiki/Atomic/GCCMM?action=AttachFile&do=view&target=libatomic.c

I added __atomic_is_lock_free for a handful of architectures where its absence immediately broke the OpenSSL build, but there are lots more.
>How-To-Repeat:
% cat >foo.c <<EOF
#include <stdatomic.h>

_Atomic struct { int x[32]; } s;

int
main(void)
{
    return atomic_load(&s).x[0];
}
EOF
% gcc -c -fno-inline-atomics foo.c
/usr/bin/ld: /tmp/ccfArqpG.o: in function `main':
foo.c:(.text+0x24): undefined reference to `__atomic_load'
collect2: error: ld returned 1 exit status

>Fix:
Yes, please!

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/57312: Missing atomic symbols generated by gcc
Date: Thu, 30 Mar 2023 17:33:28 +0200

 On Thu, Mar 30, 2023 at 03:20:00PM +0000, campbell+netbsd@mumble.net wrote:
 > Cases where symbols are missing:
 > 
 > - On architectures that don't natively have CAS, like sparc, hppa, and early mips.
 > - For objects of unnaturally large sizes, for which atomic_is_lock_free is false and locking is required.

 We have some tests for some of these symbolse in src/tests/lib/libc/atomic.

 > - When the -fno-inline-atomics flag is passed.

 We should probably build a second version of all of the tests with this
 flag added.

 That way we can actually test the libc version (instead of the builtin
 code generated for most cases in regular builds on most cpus).

 Keeping the original version with (most of the time) inlined code
 and test that as well is good (to find bugs in the compiler integration).

 Martin

From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: lib/57312: Missing atomic symbols generated by gcc
Date: Thu, 30 Mar 2023 23:00:30 +0200

 Am Thu, Mar 30, 2023 at 03:20:00PM +0000 schrieb campbell+netbsd@mumble.net:
 > libc is missing many of the __atomic_* symbols that gcc generates references to for certain out-of-line cases of the C11 stdatomic.h API.
 > 
 > Cases where symbols are missing:
 > 
 > - On architectures that don't natively have CAS, like sparc, hppa, and early mips.
 > - For objects of unnaturally large sizes, for which atomic_is_lock_free is false and locking is required.
 > - When the -fno-inline-atomics flag is passed.
 > 
 > We probably need to define all the symbols listed here:
 > https://gcc.gnu.org/wiki/Atomic/GCCMM?action=AttachFile&do=view&target=libatomic.c

 > 
 > I added __atomic_is_lock_free for a handful of architectures where its absence immediately broke the OpenSSL build, but there are lots more.

 I strongly object to adding implementations that have hidden bugs when
 used with shared memory, signals and other situations. I'd go a step
 further and would ask to de-orbit SPARCv8 SMP just for that alone. HPPA
 etc doesn't matter as RAS is fine for shared memory.

 I'd also note that the whole atomic API is majorly broken for the
 non-lockfree case, but I guess no one else cares enough about the hidden
 bugs... For those that doesn't care, they can use -latomic.

 Joerg

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/57312: Missing atomic symbols generated by gcc
Date: Sat, 1 Apr 2023 23:14:09 +0000

 On Thu, Mar 30, 2023 at 09:05:01PM +0000, Joerg Sonnenberger wrote:
  >  I strongly object to adding implementations that have hidden bugs when
  >  used with shared memory, signals and other situations. I'd go a step
  >  further and would ask to de-orbit SPARCv8 SMP just for that alone. HPPA
  >  etc doesn't matter as RAS is fine for shared memory.
  >  
  >  I'd also note that the whole atomic API is majorly broken for the
  >  non-lockfree case, but I guess no one else cares enough about the hidden
  >  bugs... For those that doesn't care, they can use -latomic.

 Unfortunately, you have to fight the war with the standard you have,
 not the standard you want.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Taylor R Campbell <riastradh@NetBSD.org>
To: Joerg Sonnenberger <joerg@bec.de>
Cc: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: lib/57312: Missing atomic symbols generated by gcc
Date: Mon, 3 Apr 2023 08:10:31 +0000

 > Date: Thu, 30 Mar 2023 21:05:01 +0000 (UTC)
 > From: Joerg Sonnenberger <joerg@bec.de>
 > 
 > I strongly object to adding implementations that have hidden bugs when
 > used with shared memory, signals and other situations. I'd go a step
 > further and would ask to de-orbit SPARCv8 SMP just for that alone. HPPA
 > etc doesn't matter as RAS is fine for shared memory.

 These aren't hidden bugs.  They are spelled out in the C standard:

    When the processing of the abstract machine is interrupted by
    receipt of a signal, the values of objects that are neither
    lock-free atomic objects nor of type volatile sig_atomic_t are
    unspecified....  The value of any object modified by the handler
    that is neither a lock-free atomic nor of type volatile
    sig_atomic_t becomes indeterminate when the handler exits....

 > I'd also note that the whole atomic API is majorly broken for the
 > non-lockfree case, but I guess no one else cares enough about the hidden
 > bugs... For those that doesn't care, they can use -latomic.

 Is this part of the contract of using C11 in NetBSD?  If so, we should
 really ship libatomic.

Home	PR Database Search