NetBSD Problem Report #53051

From martin@aprisoft.de  Sat Feb 24 19:18:33 2018
Return-Path: <martin@aprisoft.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-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 47FF37A1ED
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 24 Feb 2018 19:18:33 +0000 (UTC)
Message-Id: <20180224191824.64C9E5CC761@emmas.aprisoft.de>
Date: Sat, 24 Feb 2018 20:18:24 +0100 (CET)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: __atomic_is_lock_free missing on NetBSD/sparc
X-Send-Pr-Version: 3.95

>Number:         53051
>Category:       lib
>Synopsis:       __atomic_is_lock_free missing on NetBSD/sparc
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Feb 24 19:20:00 +0000 2018
>Closed-Date:    
>Last-Modified:  Sun Dec 23 21:25:00 +0000 2018
>Originator:     Martin Husemann
>Release:        NetBSD 8.99.12
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD nelly.aprisoft.de 8.99.12 NetBSD 8.99.12 (NELLY) #22: Mon Feb 19 13:10:27 CET 2018 martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/sparc64/compile/NELLY sparc
Architecture: sparc
Machine: sparc
>Description:

After switching to gcc 6.4 some pkgsrc software fails to build:

./libcrypto.so: undefined reference to `__atomic_is_lock_free'


>How-To-Repeat:

Build wip/openssl110

>Fix:
n/a

>Release-Note:

>Audit-Trail:
From: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/53051: __atomic_is_lock_free missing on NetBSD/sparc
Date: Sat, 24 Feb 2018 20:19:09 +0000

 interesting thing, I couldn't find where it is defined for me.
 I am using this small file to test it out:

 int CRYPTO_atomic_add(long long int *val) {
 	if (__atomic_is_lock_free(sizeof(*val), val)) {
 		return 1;
 	} else {
 		return 0;
 	}
 }

 int main() {
 	long long int a=2;
 	return CRYPTO_atomic_add(&a);
 }


 and, on amd64, gcc -c test.c doesn't produce a reference to __atomic_is_lock_free.
 but if I am trying the vax cross compiler I have (gcc-trunk and netbsd),
 it does.


 Note atomic_is_lock_free is C11, though the GCC-provided stdatomic.h
 will map it to its internal function.

From: maya@netbsd.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/53051: __atomic_is_lock_free missing on NetBSD/sparc
Date: Sat, 24 Feb 2018 20:47:46 +0000

 Never mind, the documentation even says it out loud (thanks for someone
 who read it out for me... :-))

      This built-in function returns true if objects of SIZE bytes always
      generate lock-free atomic instructions for the target
      architecture.  If the built-in function is not known to be
      lock-free, a call is made to a runtime routine named
      `__atomic_is_lock_free'.

Responsible-Changed-From-To: toolchain-manager->lib-bug-people
Responsible-Changed-By: maya@NetBSD.org
Responsible-Changed-When: Sat, 24 Feb 2018 20:51:24 +0000
Responsible-Changed-Why:
Toolchain behaving as documented. we need to provide this function.


From: David Young <dyoung@pobox.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/53051: __atomic_is_lock_free missing on NetBSD/sparc
Date: Sat, 24 Feb 2018 15:37:03 -0600

 On Sat, Feb 24, 2018 at 08:50:01PM +0000, maya@netbsd.org wrote:
 > The following reply was made to PR toolchain/53051; it has been noted by GNATS.
 > 
 > From: maya@netbsd.org
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: toolchain/53051: __atomic_is_lock_free missing on NetBSD/sparc
 > Date: Sat, 24 Feb 2018 20:47:46 +0000
 > 
 >  Never mind, the documentation even says it out loud (thanks for someone
 >  who read it out for me... :-))
 >  
 >       This built-in function returns true if objects of SIZE bytes always
 >       generate lock-free atomic instructions for the target
 >       architecture.  If the built-in function is not known to be
 >       lock-free, a call is made to a runtime routine named
 >       `__atomic_is_lock_free'.

 That paragraph may oversimplify things a bit?  What if an object
 is SIZE bytes but not naturally aligned?

 Some readers may misunderstand "lock-free" to mean a non-interlocked
 memory access (i.e., without LOCK prefix on x86) such as the
 atomic_*_ni(3) functions provide on NetBSD, when the meaning is more
 like a mutex, unless *I* have misunderstood.

 Dave

 -- 
 David Young
 dyoung@pobox.com    Urbana, IL    (217) 721-9981

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, martin@NetBSD.org
Subject: Re: toolchain/53051: __atomic_is_lock_free missing on NetBSD/sparc
Date: Sat, 24 Feb 2018 23:02:00 +0100

 On Sat, Feb 24, 2018 at 09:40:00PM +0000, David Young wrote:
 >  >  Never mind, the documentation even says it out loud (thanks for someone
 >  >  who read it out for me... :-))
 >  >  
 >  >       This built-in function returns true if objects of SIZE bytes always
 >  >       generate lock-free atomic instructions for the target
 >  >       architecture.  If the built-in function is not known to be
 >  >       lock-free, a call is made to a runtime routine named
 >  >       `__atomic_is_lock_free'.
 >  
 >  That paragraph may oversimplify things a bit?  What if an object
 >  is SIZE bytes but not naturally aligned?

 The function is only for use with declared atomic storage. That includes
 correct alignment (which is not necessarily the natural alignment).

 Joerg

State-Changed-From-To: open->closed
State-Changed-By: martin@NetBSD.org
State-Changed-When: Fri, 09 Mar 2018 14:46:22 +0000
State-Changed-Why:
fixed


State-Changed-From-To: closed->open
State-Changed-By: maya@NetBSD.org
State-Changed-When: Fri, 09 Mar 2018 15:52:56 +0000
State-Changed-Why:
original issue is worked around (at a cost, too). we need to provide this function, for other things as well.


From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/53051 (__atomic_is_lock_free missing on NetBSD/sparc)
Date: Fri, 9 Mar 2018 17:12:49 +0100

 It would be great to add something triggering this to the link-time
 tests in src/tests/lib/libc/sync.

 Martin

From: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/53051: __atomic_is_lock_free missing on NetBSD/sparc
Date: Sat, 22 Dec 2018 17:51:13 +0000

 Worth noting that netbsd *does* have locked atomics for SPARC.
 They are in src/common/lib/libc/arch/sparc/atomic

From: Jason Thorpe <thorpej@me.com>
To: "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>
Cc: lib-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 "martin@netbsd.org" <martin@NetBSD.org>
Subject: Re: lib/53051: __atomic_is_lock_free missing on NetBSD/sparc
Date: Sat, 22 Dec 2018 11:05:27 -0800

 > On Dec 22, 2018, at 9:55 AM, coypu@sdf.org wrote:
 >=20
 > The following reply was made to PR lib/53051; it has been noted by =
 GNATS.
 >=20
 > From: coypu@sdf.org
 > To: gnats-bugs@NetBSD.org
 > Cc:=20
 > Subject: Re: lib/53051: __atomic_is_lock_free missing on NetBSD/sparc
 > Date: Sat, 22 Dec 2018 17:51:13 +0000
 >=20
 > Worth noting that netbsd *does* have locked atomics for SPARC.
 > They are in src/common/lib/libc/arch/sparc/atomic

 So, the way I understand this is that, on the "sparc" architecture, this =
 would return true on a uniprocessor system and false on a multiprocessor =
 system.  This is because on a multiprocessor system, our atomics always =
 use an interlock table because sparc only has LDSTUB (and all of the =
 various operations are implemented on top of the interlocked =
 compare-and-swap primitive), whereas on a uniprocessor, it's implemented =
 using a restartable atomic sequence.

 That, however, assumes that all of the C11 atomic calls get vectored =
 through our libc implementation (which is based on the Solaris atomics =
 API) ... all bets are off if they end up using some random =
 implementation in libgcc.

 -- thorpej

From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/53051: __atomic_is_lock_free missing on NetBSD/sparc
Date: Sun, 23 Dec 2018 00:22:54 +0000

 No, sorry, I got confused. This is definitely kernel only despite being
 in common/.

 NetBSD lacks APIs to make this kind of thing possible.

From: Martin Husemann <martin@duskware.de>
To: Jason Thorpe <thorpej@me.com>
Cc: "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>,
	lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, "martin@netbsd.org" <martin@NetBSD.org>
Subject: Re: lib/53051: __atomic_is_lock_free missing on NetBSD/sparc
Date: Sun, 23 Dec 2018 11:23:18 +0100

 On Sat, Dec 22, 2018 at 11:05:27AM -0800, Jason Thorpe wrote:
 > So, the way I understand this is that, on the "sparc" architecture,
 > this would return true on a uniprocessor system and false on a
 > multiprocessor system.

 My understanding is that it would have to always return false - there
 are effectively no lock free atomics on sparcv8 or earlier.

 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, martin@NetBSD.org
Subject: Re: lib/53051: __atomic_is_lock_free missing on NetBSD/sparc
Date: Sun, 23 Dec 2018 22:09:18 +0100

 On Sun, Dec 23, 2018 at 10:25:00AM +0000, Martin Husemann wrote:
 > The following reply was made to PR lib/53051; it has been noted by GNATS.
 > 
 >  On Sat, Dec 22, 2018 at 11:05:27AM -0800, Jason Thorpe wrote:
 >  > So, the way I understand this is that, on the "sparc" architecture,
 >  > this would return true on a uniprocessor system and false on a
 >  > multiprocessor system.
 >  
 >  My understanding is that it would have to always return false - there
 >  are effectively no lock free atomics on sparcv8 or earlier.

 The complication is that the ABI kind of assumes that you can mix code
 compiled with different target CPU flags and they can interoperate. I.e.
 code targetting v8a and code targetting the generic v8 should be able to
 interoperate. That's painful in the current code structure.

 Joerg

>Unformatted:

Home	PR Database Search