NetBSD Problem Report #57515

From www@netbsd.org  Sat Jul  8 16:06:15 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 30F9B1A923E
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  8 Jul 2023 16:06:15 +0000 (UTC)
Message-Id: <20230708160614.0754C1A9241@mollari.NetBSD.org>
Date: Sat,  8 Jul 2023 16:06:13 +0000 (UTC)
From: koachan+netbsd@protonmail.com
Reply-To: koachan+netbsd@protonmail.com
To: gnats-bugs@NetBSD.org
Subject: sparc32 GCC defaults to SC memory ordering, which is not true on SPARCv8 processors
X-Send-Pr-Version: www-1.0

>Number:         57515
>Category:       port-sparc
>Synopsis:       sparc32 GCC defaults to SC memory ordering, which is not true on SPARCv8 processors
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-sparc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 08 16:10:00 +0000 2023
>Last-Modified:  Sun Jul 09 12:20:01 +0000 2023
>Originator:     Koakuma
>Release:        9.3
>Organization:
N/A
>Environment:
NetBSD nbsd 9.3 NetBSD 9.3 (GENERIC.MP) #0: Thu Aug 4 15:30:37 UTC 2022 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/sparc/compile/GENERIC.MP sparc
>Description:
Currently, when targeting sparc32 processors, GCC assumes that the hardware has sequentially consistent memory ordering by default.
This can cause problems when running generated binaries on v8 and later processors, which uses weaker TSO ordering, because GCC does not emit the necessary barrier instructions for ordering.

Upstream report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592
>How-To-Repeat:
Compile this C++ code with `-O2`:
```
#include <atomic>

long load(std::atomic<long> ptr) {
    return ptr.load();
}

void store(std::atomic<long> ptr, long val) {
    ptr.store(val);
}
```

It should generate necessary `ldstub` barrier instructions, as shown here (on the -mcpu=v8 window): https://godbolt.org/z/oq8nnK6Th
But currently, unless -mcpu=v8 is passed explicitly, NetBSD's bundled GCC does not generate that.
>Fix:
N/A

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-sparc/57515: sparc32 GCC defaults to SC memory ordering,
 which is not true on SPARCv8 processors
Date: Sat, 8 Jul 2023 19:48:09 +0200

 I don't think this is a bug. We default to v7 everywhere on 32bit sparc.

 Martin

From: Taylor R Campbell <riastradh@NetBSD.org>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57515: sparc32 GCC defaults to SC memory ordering, which is not true on SPARCv8 processors
Date: Sat, 8 Jul 2023 20:19:37 +0000

 > Date: Sat, 8 Jul 2023 19:48:09 +0200
 > From: Martin Husemann <martin@duskware.de>
 > 
 > I don't think this is a bug. We default to v7 everywhere on 32bit
 > sparc.

 Consider the following program:

 int
 stldmul(_Atomic int *p, _Atomic int *q, int x)
 {
 	int y;

 	__atomic_store(p, &x, __ATOMIC_SEQ_CST);
 	__atomic_load(q, &y, __ATOMIC_SEQ_CST);

 	return x * y;
 }


 Compiling it with gcc -mcpu=v7 gives:

 00000000 <stldmul>:
    0:	9d e3 bf a0 	save  %sp, -96, %sp
    4:	f4 26 00 00 	st  %i2, [ %i0 ]
    8:	d0 06 40 00 	ld  [ %i1 ], %o0
    c:	40 00 00 00 	call  c <stldmul+0xc>
 			c: R_SPARC_WDISP30	.umul
   10:	92 10 00 1a 	mov  %i2, %o1
   14:	81 c7 e0 08 	ret 
   18:	91 e8 00 08 	restore  %g0, %o0, %o0


 Compiling it with gcc -mcpu=v8 gives:

 00000000 <stldmul>:
    0:	81 43 c0 00 	stbar 
    4:	d4 22 00 00 	st  %o2, [ %o0 ]
    8:	81 43 c0 00 	stbar 
    c:	c0 6b bf ff 	ldstub  [ %sp + -1 ], %g0
   10:	c0 6b bf ff 	ldstub  [ %sp + -1 ], %g0
   14:	d0 02 40 00 	ld  [ %o1 ], %o0
   18:	81 c3 e0 08 	retl 
   1c:	90 5a 00 0a 	smul  %o0, %o2, %o0


 If a `NetBSD/sparc' userland is supposed to work on sparcv7 and
 sparcv8 CPUs, well, that's a problem, because these are both broken:

 - The -mcpu=v7 output is broken on sparcv8 CPUs, which run in TSO,
   because it's missing an ldstub instruction between the store at 4
   and the load at 8 to guarantee the sequential consistency ordering
   the program asked for, e.g. for Dekker's algorithm.

   (The -mcpu=v8 output does more than it needs -- a single ldstub is
   enough, no need for stbar or a second ldstub, but that's a speed
   issue, not a correctness issue.)

 - The -mcpu=v8 output is broken on sparcv7 CPUs because it uses the
   smul instruction, which doesn't exist in sparcv7, if I recall
   correctly.

   (If my memory has faded and smul does exist but just isn't used by
   gcc for some reason, there's probably some other sparcv8 instruction
   that doesn't exist on sparcv7 which gcc will use with `-mcpu=v7'.)

 However, gcc developers don't view this as an issue -- `compile for V8
 if you want to run on V8':

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592


 I think maybe the right thing is to have `-mcpu=v7 -mmemory-model=tso'
 generate the ldstub, and use that in NetBSD/sparc; that way the
 default semantics in a non-NetBSD gcc build for a solitary `-mcpu=v7'
 option can still be as if you had passed `-mcpu=v7 -mmemory-model=sc',
 as it is today.

 But currently that doesn't work because the rules to generate memory
 barrier instructions or equivalent are all gated on TARGET_V8 ||
 TARGET_V9, so they just don't kick in for `-mcpu=v7' even if you also
 pass `-mmemory-model=tso'.

From: Martin Husemann <martin@duskware.de>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57515: sparc32 GCC defaults to SC memory ordering, which is
 not true on SPARCv8 processors
Date: Sat, 8 Jul 2023 23:24:50 +0200

 On Sat, Jul 08, 2023 at 08:19:37PM +0000, Taylor R Campbell wrote:
 > If a `NetBSD/sparc' userland is supposed to work on sparcv7 and
 > sparcv8 CPUs, well, that's a problem, because these are both broken:

 Well, I don't know about v8 and early details, but kinda assumed it
 would be similar to v9 where it is under (kernel's) software controll
 (and binaries get run with the memory model they are compiled for).

 If that is not the case we should make v8 the default, adjust documentation
 and provide support for v7 as source only. Few machines are left over
 in working condition.

 Martin

From: Taylor R Campbell <riastradh@NetBSD.org>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57515: sparc32 GCC defaults to SC memory ordering, which is
	not true on SPARCv8 processors
Date: Sat, 8 Jul 2023 21:40:46 +0000

 > Date: Sat, 8 Jul 2023 23:24:50 +0200
 > From: Martin Husemann <martin@duskware.de>
 >=20
 > On Sat, Jul 08, 2023 at 08:19:37PM +0000, Taylor R Campbell wrote:
 > > If a `NetBSD/sparc' userland is supposed to work on sparcv7 and
 > > sparcv8 CPUs, well, that's a problem, because these are both broken:
 >=20
 > Well, I don't know about v8 and early details, but kinda assumed it
 > would be similar to v9 where it is under (kernel's) software controll
 > (and binaries get run with the memory model they are compiled for).

 Ah -- it is possible that the v7-targeted compiler will generate
 binaries with memory model SC instead of TSO, in which case there's no
 bug here, but there is a substantial performance impact on MP sparcv8
 by forcing SC for everything.

 (There's also a performance impact on sparcv8 by forcing out-of-line
 multiplication -- but if I recall correctly we have libc substitute on
 sparcv8 via ld.so.conf that uses the CPU instructions, at least,
 instead of software multiplication.)

 > If that is not the case we should make v8 the default, adjust documentati=
 on
 > and provide support for v7 as source only. Few machines are left over
 > in working condition.

 That's an option too, but I bet it could be made to work reasonably
 well with a small tweak to gcc so that NetBSD can ask for -mcpu=3Dv7
 -mmemory-model=3Dtso instead of having -mcpu=3Dv7 ignore -mmemory-model,
 if someone is willing to do the work and testing for it.

From: Koakuma <koachan+netbsd@protonmail.com>
To: gnats-bugs@netbsd.org
Cc: port-sparc-maintainer@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/57515: sparc32 GCC defaults to SC memory ordering, which is not true on SPARCv8 processors
Date: Sun, 09 Jul 2023 02:17:25 +0000

 This is a multi-part message in MIME format.

 --b1_Y36XyXGKisqLppvKhv5Ac4It4jlXa9BoMSKISUJYU7o
 Content-Type: text/plain; charset=utf-8
 Content-Transfer-Encoding: quoted-printable

 Martin Husemann wrote:
 > Well, I don't know about v8 and early details, but kinda assumed it
 > would be similar to v9 where it is under (kernel's) software controll
 > (and binaries get run with the memory model they are compiled for).

 Even if it works that way, v8 and v9 does not have sequential consistency
 as a supported memory model, so binaries targeted for v7 might still run
 wrongly on later processors anyway.

 Taylor R Campbell wrote:
 > That's an option too, but I bet it could be made to work reasonably
 > well with a small tweak to gcc so that NetBSD can ask for -mcpu=3Dv7
 > -mmemory-model=3Dtso instead of having -mcpu=3Dv7 ignore -mmemory-model,
 > if someone is willing to do the work and testing for it.

 I just made this small patch that removes all the conditionals for
 barrier instructions (except for `stbar` and `membar` since those are
 not available in v7) and changes the default memory ordering to TSO.
 Seems to get it to emit the proper barriers for me, but probably could
 be done a little bit better, since I am not familiar with GCC internals.
 --b1_Y36XyXGKisqLppvKhv5Ac4It4jlXa9BoMSKISUJYU7o
 Content-Type: text/x-patch; name=ordering.patch
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename=ordering.patch

 ZGlmZiAtLWdpdCBhL2V4dGVybmFsL2dwbDMvZ2NjLm9sZC9kaXN0L2djYy9jb25maWcvc3BhcmMv
 cHJlZGljYXRlcy5tZCBiL2V4dGVybmFsL2dwbDMvZ2NjLm9sZC9kaXN0L2djYy9jb25maWcvc3Bh
 cmMvcHJlZGljYXRlcy5tZAppbmRleCA0MjMxNmFkYzkuLmE3NDNmMWNhYSAxMDA2NDQKLS0tIGEv
 ZXh0ZXJuYWwvZ3BsMy9nY2Mub2xkL2Rpc3QvZ2NjL2NvbmZpZy9zcGFyYy9wcmVkaWNhdGVzLm1k
 CisrKyBiL2V4dGVybmFsL2dwbDMvZ2NjLm9sZC9kaXN0L2djYy9jb25maWcvc3BhcmMvcHJlZGlj
 YXRlcy5tZApAQCAtNzgsNiArNzgsMTEgQEAKIChkZWZpbmVfcHJlZGljYXRlICJjb25zdF9kb3Vi
 bGVfb3JfdmVjdG9yX29wZXJhbmQiCiAgIChtYXRjaF9jb2RlICJjb25zdF9kb3VibGUsY29uc3Rf
 dmVjdG9yIikpCiAKKzs7IFJldHVybiB0cnVlIGlmIE9QIGlzIFplcm8uCisoZGVmaW5lX3ByZWRp
 Y2F0ZSAiemVyb19vcGVyYW5kIgorICAoYW5kIChtYXRjaF9jb2RlICJjb25zdF9pbnQiKQorICAg
 ICAgIChtYXRjaF90ZXN0ICJJTlRWQUwgKG9wKSA9PSAwIikpKQorCiA7OyBSZXR1cm4gdHJ1ZSBp
 ZiBPUCBpcyBaZXJvLCBvciBpZiB0aGUgdGFyZ2V0IGlzIFY3LgogKGRlZmluZV9wcmVkaWNhdGUg
 Inplcm9fb3Jfdjdfb3BlcmFuZCIKICAgKGFuZCAobWF0Y2hfY29kZSAiY29uc3RfaW50IikKZGlm
 ZiAtLWdpdCBhL2V4dGVybmFsL2dwbDMvZ2NjLm9sZC9kaXN0L2djYy9jb25maWcvc3BhcmMvc3Bh
 cmMuYyBiL2V4dGVybmFsL2dwbDMvZ2NjLm9sZC9kaXN0L2djYy9jb25maWcvc3BhcmMvc3BhcmMu
 YwppbmRleCA3Y2ZhOWY4MDYuLmM2NDEyN2JjMSAxMDA2NDQKLS0tIGEvZXh0ZXJuYWwvZ3BsMy9n
 Y2Mub2xkL2Rpc3QvZ2NjL2NvbmZpZy9zcGFyYy9zcGFyYy5jCisrKyBiL2V4dGVybmFsL2dwbDMv
 Z2NjLm9sZC9kaXN0L2djYy9jb25maWcvc3BhcmMvc3BhcmMuYwpAQCAtMjAwOSw3ICsyMDA5LDcg
 QEAgc3BhcmNfb3B0aW9uX292ZXJyaWRlICh2b2lkKQogICAgICAgZWxzZSBpZiAoVEFSR0VUX1Y4
 KQogCXNwYXJjX21lbW9yeV9tb2RlbCA9IFNNTV9QU087CiAgICAgICBlbHNlCi0Jc3BhcmNfbWVt
 b3J5X21vZGVsID0gU01NX1NDOworCXNwYXJjX21lbW9yeV9tb2RlbCA9IFNNTV9UU087CiAgICAg
 fQogCiAgIC8qIFN1cHBseSBhIGRlZmF1bHQgdmFsdWUgZm9yIGFsaWduX2Z1bmN0aW9ucy4gICov
 CmRpZmYgLS1naXQgYS9leHRlcm5hbC9ncGwzL2djYy5vbGQvZGlzdC9nY2MvY29uZmlnL3NwYXJj
 L3N5bmMubWQgYi9leHRlcm5hbC9ncGwzL2djYy5vbGQvZGlzdC9nY2MvY29uZmlnL3NwYXJjL3N5
 bmMubWQKaW5kZXggMDk2MzcyYzA5Li5lZTg1YTY1M2MgMTAwNjQ0Ci0tLSBhL2V4dGVybmFsL2dw
 bDMvZ2NjLm9sZC9kaXN0L2djYy9jb25maWcvc3BhcmMvc3luYy5tZAorKysgYi9leHRlcm5hbC9n
 cGwzL2djYy5vbGQvZGlzdC9nY2MvY29uZmlnL3NwYXJjL3N5bmMubWQKQEAgLTI1LDcgKzI1LDcg
 QEAKIAogKGRlZmluZV9leHBhbmQgIm1lbV90aHJlYWRfZmVuY2UiCiAgIFsobWF0Y2hfb3BlcmFu
 ZDpTSSAwICJjb25zdF9pbnRfb3BlcmFuZCIpXQotICAiVEFSR0VUX1Y4IHx8IFRBUkdFVF9WOSIK
 KyAgIiIKIHsKICAgZW51bSBtZW1tb2RlbCBtb2RlbCA9IChlbnVtIG1lbW1vZGVsKSBJTlRWQUwg
 KG9wZXJhbmRzWzBdKTsKICAgc3BhcmNfZW1pdF9tZW1iYXJfZm9yX21vZGVsIChtb2RlbCwgMywg
 Myk7CkBAIC0zNiw3ICszNiw3IEBACiAgIFsoc2V0IChtYXRjaF9kdXAgMSkKIAkodW5zcGVjOkJM
 SyBbKG1hdGNoX2R1cCAxKSAobWF0Y2hfb3BlcmFuZDpTSSAwICJjb25zdF9pbnRfb3BlcmFuZCIp
 XQogCQkgICAgVU5TUEVDX01FTUJBUikpXQotICAiVEFSR0VUX1Y4IHx8IFRBUkdFVF9WOSIKKyAg
 IiIKIHsKICAgb3BlcmFuZHNbMV0gPSBnZW5fcnR4X01FTSAoQkxLbW9kZSwgZ2VuX3J0eF9TQ1JB
 VENIIChQbW9kZSkpOwogICBNRU1fVk9MQVRJTEVfUCAob3BlcmFuZHNbMV0pID0gMTsKQEAgLTQ5
 LDcgKzQ5LDcgQEAKIDs7IGlnbm9yZSBhbGwgc3VjaCBiYXJyaWVycyBvbiBTcGFyYyBWNy4KIChk
 ZWZpbmVfaW5zbiAiKm1lbWJhcl9lbXB0eSIKICAgWyhzZXQgKG1hdGNoX29wZXJhbmQ6QkxLIDAg
 IiIgIiIpCi0JKHVuc3BlYzpCTEsgWyhtYXRjaF9kdXAgMCkgKG1hdGNoX29wZXJhbmQ6U0kgMSAi
 emVyb19vcl92N19vcGVyYW5kIildCisJKHVuc3BlYzpCTEsgWyhtYXRjaF9kdXAgMCkgKG1hdGNo
 X29wZXJhbmQ6U0kgMSAiemVyb19vcGVyYW5kIildCiAJCSAgICBVTlNQRUNfTUVNQkFSKSldCiAg
 ICIiCiAgICIiCkBAIC03Niw3ICs3Niw3IEBACiAoZGVmaW5lX2luc24gIiptZW1iYXJfc3RvcmVs
 b2FkIgogICBbKHNldCAobWF0Y2hfb3BlcmFuZDpCTEsgMCAiIiAiIikKIAkodW5zcGVjOkJMSyBb
 KG1hdGNoX2R1cCAwKSAoY29uc3RfaW50IDIpXSBVTlNQRUNfTUVNQkFSKSldCi0gICJUQVJHRVRf
 VjggJiYgIVRBUkdFVF9MRU9OMyIKKyAgIiFUQVJHRVRfVjkgJiYgIVRBUkdFVF9MRU9OMyIKICAg
 Imxkc3R1Ylx0WyUlc3AtMV0sICUlZzAiCiAgIFsoc2V0X2F0dHIgInR5cGUiICJtdWx0aSIpXSkK
 IApAQCAtMjYyLDcgKzI2Miw3IEBACiAgICAobWF0Y2hfb3BlcmFuZDpTSSAxICJtZW1vcnlfb3Bl
 cmFuZCIgIiIpCiAgICAobWF0Y2hfb3BlcmFuZDpTSSAyICJyZWdpc3Rlcl9vcGVyYW5kIiAiIikK
 ICAgIChtYXRjaF9vcGVyYW5kOlNJIDMgImNvbnN0X2ludF9vcGVyYW5kIiAiIildCi0gICIoVEFS
 R0VUX1Y4IHx8IFRBUkdFVF9WOSkgJiYgIXNwYXJjX2ZpeF91dDY5OSIKKyAgIiFzcGFyY19maXhf
 dXQ2OTkiCiB7CiAgIGVudW0gbWVtbW9kZWwgbW9kZWwgPSAoZW51bSBtZW1tb2RlbCkgSU5UVkFM
 IChvcGVyYW5kc1szXSk7CiAKQEAgLTI3OCw3ICsyNzgsNyBAQAogCQkJICAgIFVOU1BFQ1ZfU1dB
 UCkpCiAgICAoc2V0IChtYXRjaF9kdXAgMSkKIAkobWF0Y2hfb3BlcmFuZDpTSSAyICJyZWdpc3Rl
 cl9vcGVyYW5kIiAiMCIpKV0KLSAgIihUQVJHRVRfVjggfHwgVEFSR0VUX1Y5KSAmJiAhc3BhcmNf
 Zml4X3V0Njk5IgorICAiIXNwYXJjX2ZpeF91dDY5OSIKIHsKICAgaWYgKHNwYXJjX2ZpeF9ncjcx
 MnJjKQogICAgIHJldHVybiAiLmFsaWduXHQxNlxuXHRzd2FwXHQlMSwgJTAiOwpkaWZmIC0tZ2l0
 IGEvZXh0ZXJuYWwvZ3BsMy9nY2MvZGlzdC9nY2MvY29uZmlnL3NwYXJjL3ByZWRpY2F0ZXMubWQg
 Yi9leHRlcm5hbC9ncGwzL2djYy9kaXN0L2djYy9jb25maWcvc3BhcmMvcHJlZGljYXRlcy5tZApp
 bmRleCA0MjMxNmFkYzkuLmE3NDNmMWNhYSAxMDA2NDQKLS0tIGEvZXh0ZXJuYWwvZ3BsMy9nY2Mv
 ZGlzdC9nY2MvY29uZmlnL3NwYXJjL3ByZWRpY2F0ZXMubWQKKysrIGIvZXh0ZXJuYWwvZ3BsMy9n
 Y2MvZGlzdC9nY2MvY29uZmlnL3NwYXJjL3ByZWRpY2F0ZXMubWQKQEAgLTc4LDYgKzc4LDExIEBA
 CiAoZGVmaW5lX3ByZWRpY2F0ZSAiY29uc3RfZG91YmxlX29yX3ZlY3Rvcl9vcGVyYW5kIgogICAo
 bWF0Y2hfY29kZSAiY29uc3RfZG91YmxlLGNvbnN0X3ZlY3RvciIpKQogCis7OyBSZXR1cm4gdHJ1
 ZSBpZiBPUCBpcyBaZXJvLgorKGRlZmluZV9wcmVkaWNhdGUgInplcm9fb3BlcmFuZCIKKyAgKGFu
 ZCAobWF0Y2hfY29kZSAiY29uc3RfaW50IikKKyAgICAgICAobWF0Y2hfdGVzdCAiSU5UVkFMIChv
 cCkgPT0gMCIpKSkKKwogOzsgUmV0dXJuIHRydWUgaWYgT1AgaXMgWmVybywgb3IgaWYgdGhlIHRh
 cmdldCBpcyBWNy4KIChkZWZpbmVfcHJlZGljYXRlICJ6ZXJvX29yX3Y3X29wZXJhbmQiCiAgIChh
 bmQgKG1hdGNoX2NvZGUgImNvbnN0X2ludCIpCmRpZmYgLS1naXQgYS9leHRlcm5hbC9ncGwzL2dj
 Yy9kaXN0L2djYy9jb25maWcvc3BhcmMvc3BhcmMuYyBiL2V4dGVybmFsL2dwbDMvZ2NjL2Rpc3Qv
 Z2NjL2NvbmZpZy9zcGFyYy9zcGFyYy5jCmluZGV4IDdjZmE5ZjgwNi4uYzFkODlkOGRmIDEwMDY0
 NAotLS0gYS9leHRlcm5hbC9ncGwzL2djYy9kaXN0L2djYy9jb25maWcvc3BhcmMvc3BhcmMuYwor
 KysgYi9leHRlcm5hbC9ncGwzL2djYy9kaXN0L2djYy9jb25maWcvc3BhcmMvc3BhcmMuYwpAQCAt
 MjAwOSw5ICsyMDA5LDkgQEAgc3BhcmNfb3B0aW9uX292ZXJyaWRlICh2b2lkKQogICAgICAgZWxz
 ZSBpZiAoVEFSR0VUX1Y4KQogCXNwYXJjX21lbW9yeV9tb2RlbCA9IFNNTV9QU087CiAgICAgICBl
 bHNlCi0Jc3BhcmNfbWVtb3J5X21vZGVsID0gU01NX1NDOworCXNwYXJjX21lbW9yeV9tb2RlbCA9
 IFNNTV9UU087CiAgICAgfQotCisgIGFib3J0KCk7CiAgIC8qIFN1cHBseSBhIGRlZmF1bHQgdmFs
 dWUgZm9yIGFsaWduX2Z1bmN0aW9ucy4gICovCiAgIGlmIChmbGFnX2FsaWduX2Z1bmN0aW9ucyAm
 JiAhc3RyX2FsaWduX2Z1bmN0aW9ucykKICAgICB7CmRpZmYgLS1naXQgYS9leHRlcm5hbC9ncGwz
 L2djYy9kaXN0L2djYy9jb25maWcvc3BhcmMvc3luYy5tZCBiL2V4dGVybmFsL2dwbDMvZ2NjL2Rp
 c3QvZ2NjL2NvbmZpZy9zcGFyYy9zeW5jLm1kCmluZGV4IDA5NjM3MmMwOS4uOTdjODNmOGY3IDEw
 MDY0NAotLS0gYS9leHRlcm5hbC9ncGwzL2djYy9kaXN0L2djYy9jb25maWcvc3BhcmMvc3luYy5t
 ZAorKysgYi9leHRlcm5hbC9ncGwzL2djYy9kaXN0L2djYy9jb25maWcvc3BhcmMvc3luYy5tZApA
 QCAtMjUsNyArMjUsNyBAQAogCiAoZGVmaW5lX2V4cGFuZCAibWVtX3RocmVhZF9mZW5jZSIKICAg
 WyhtYXRjaF9vcGVyYW5kOlNJIDAgImNvbnN0X2ludF9vcGVyYW5kIildCi0gICJUQVJHRVRfVjgg
 fHwgVEFSR0VUX1Y5IgorICAiIgogewogICBlbnVtIG1lbW1vZGVsIG1vZGVsID0gKGVudW0gbWVt
 bW9kZWwpIElOVFZBTCAob3BlcmFuZHNbMF0pOwogICBzcGFyY19lbWl0X21lbWJhcl9mb3JfbW9k
 ZWwgKG1vZGVsLCAzLCAzKTsKQEAgLTM2LDcgKzM2LDcgQEAKICAgWyhzZXQgKG1hdGNoX2R1cCAx
 KQogCSh1bnNwZWM6QkxLIFsobWF0Y2hfZHVwIDEpIChtYXRjaF9vcGVyYW5kOlNJIDAgImNvbnN0
 X2ludF9vcGVyYW5kIildCiAJCSAgICBVTlNQRUNfTUVNQkFSKSldCi0gICJUQVJHRVRfVjggfHwg
 VEFSR0VUX1Y5IgorICAiIgogewogICBvcGVyYW5kc1sxXSA9IGdlbl9ydHhfTUVNIChCTEttb2Rl
 LCBnZW5fcnR4X1NDUkFUQ0ggKFBtb2RlKSk7CiAgIE1FTV9WT0xBVElMRV9QIChvcGVyYW5kc1sx
 XSkgPSAxOwpAQCAtNDksNyArNDksNyBAQAogOzsgaWdub3JlIGFsbCBzdWNoIGJhcnJpZXJzIG9u
 IFNwYXJjIFY3LgogKGRlZmluZV9pbnNuICIqbWVtYmFyX2VtcHR5IgogICBbKHNldCAobWF0Y2hf
 b3BlcmFuZDpCTEsgMCAiIiAiIikKLQkodW5zcGVjOkJMSyBbKG1hdGNoX2R1cCAwKSAobWF0Y2hf
 b3BlcmFuZDpTSSAxICJ6ZXJvX29yX3Y3X29wZXJhbmQiKV0KKwkodW5zcGVjOkJMSyBbKG1hdGNo
 X2R1cCAwKSAobWF0Y2hfb3BlcmFuZDpTSSAxICJ6ZXJvX29wZXJhbmQiKV0KIAkJICAgIFVOU1BF
 Q19NRU1CQVIpKV0KICAgIiIKICAgIiIKQEAgLTcyLDExICs3MiwxMSBAQAogICAic3RiXHQlJWcw
 LCBbJSVzcC0xXSIKICAgWyhzZXRfYXR0ciAidHlwZSIgInN0b3JlIildKQogCi07OyBGb3IgVjgs
 IExEU1RVQiBoYXMgdGhlIGVmZmVjdCBvZiBtZW1iYXIgI1N0b3JlTG9hZC4KKzs7IEZvciBWNy9W
 OCwgTERTVFVCIGhhcyB0aGUgZWZmZWN0IG9mIG1lbWJhciAjU3RvcmVMb2FkLgogKGRlZmluZV9p
 bnNuICIqbWVtYmFyX3N0b3JlbG9hZCIKICAgWyhzZXQgKG1hdGNoX29wZXJhbmQ6QkxLIDAgIiIg
 IiIpCiAJKHVuc3BlYzpCTEsgWyhtYXRjaF9kdXAgMCkgKGNvbnN0X2ludCAyKV0gVU5TUEVDX01F
 TUJBUikpXQotICAiVEFSR0VUX1Y4ICYmICFUQVJHRVRfTEVPTjMiCisgICIhVEFSR0VUX1Y5ICYm
 ICFUQVJHRVRfTEVPTjMiCiAgICJsZHN0dWJcdFslJXNwLTFdLCAlJWcwIgogICBbKHNldF9hdHRy
 ICJ0eXBlIiAibXVsdGkiKV0pCiAKQEAgLTI2Miw3ICsyNjIsNyBAQAogICAgKG1hdGNoX29wZXJh
 bmQ6U0kgMSAibWVtb3J5X29wZXJhbmQiICIiKQogICAgKG1hdGNoX29wZXJhbmQ6U0kgMiAicmVn
 aXN0ZXJfb3BlcmFuZCIgIiIpCiAgICAobWF0Y2hfb3BlcmFuZDpTSSAzICJjb25zdF9pbnRfb3Bl
 cmFuZCIgIiIpXQotICAiKFRBUkdFVF9WOCB8fCBUQVJHRVRfVjkpICYmICFzcGFyY19maXhfdXQ2
 OTkiCisgICIhc3BhcmNfZml4X3V0Njk5IgogewogICBlbnVtIG1lbW1vZGVsIG1vZGVsID0gKGVu
 dW0gbWVtbW9kZWwpIElOVFZBTCAob3BlcmFuZHNbM10pOwogCkBAIC0yNzgsNyArMjc4LDcgQEAK
 IAkJCSAgICBVTlNQRUNWX1NXQVApKQogICAgKHNldCAobWF0Y2hfZHVwIDEpCiAJKG1hdGNoX29w
 ZXJhbmQ6U0kgMiAicmVnaXN0ZXJfb3BlcmFuZCIgIjAiKSldCi0gICIoVEFSR0VUX1Y4IHx8IFRB
 UkdFVF9WOSkgJiYgIXNwYXJjX2ZpeF91dDY5OSIKKyAgIiFzcGFyY19maXhfdXQ2OTkiCiB7CiAg
 IGlmIChzcGFyY19maXhfZ3I3MTJyYykKICAgICByZXR1cm4gIi5hbGlnblx0MTZcblx0c3dhcFx0
 JTEsICUwIjsK

 --b1_Y36XyXGKisqLppvKhv5Ac4It4jlXa9BoMSKISUJYU7o--

From: Taylor R Campbell <campbell@mumble.net>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: Martin Husemann <martin@duskware.de>, gnats-bugs@NetBSD.org
Subject: Re: kern/57515: sparc32 GCC defaults to SC memory ordering, which is
	not true on SPARCv8 processors
Date: Sun, 9 Jul 2023 12:17:29 +0000

 > Date: Sat, 8 Jul 2023 21:40:46 +0000
 > From: Taylor R Campbell <riastradh@NetBSD.org>
 >=20
 > > Date: Sat, 8 Jul 2023 23:24:50 +0200
 > > From: Martin Husemann <martin@duskware.de>
 > >=20
 > > On Sat, Jul 08, 2023 at 08:19:37PM +0000, Taylor R Campbell wrote:
 > > > If a `NetBSD/sparc' userland is supposed to work on sparcv7 and
 > > > sparcv8 CPUs, well, that's a problem, because these are both broken:
 > >=20
 > > Well, I don't know about v8 and early details, but kinda assumed it
 > > would be similar to v9 where it is under (kernel's) software controll
 > > (and binaries get run with the memory model they are compiled for).
 >=20
 > Ah -- it is possible that the v7-targeted compiler will generate
 > binaries with memory model SC instead of TSO, in which case there's no
 > bug here, but there is a substantial performance impact on MP sparcv8
 > by forcing SC for everything.

 It appears that:

 1. Only SPARCv9 ELF binaries can specify the memory model -- SPARCv8
    binaries cannot.  SPARCv8 doesn't appear to have a PSTATE register
    to set the memory model either.

 2. The PSTATE_MM field, and the SPARCv9 ELF header, doesn't even have
    an assignment of bits for SC (sequential consistency) -- only for
    TSO, PSO, and RMO, with the remaining possible value reserved,
    according to the SPARCv9 architecture manual and the Oracle ELF manual.

    https://web.archive.org/web/20221221170717/https://docs.oracle.com/en/op=
 erating-systems/solaris/oracle-solaris/11.4/linkers-libraries/elf-header.ht=
 ml  =20

 So unfortunately that doesn't work.

 But a modest patch to gcc -- in code that's not likely to be changing
 much -- to make `-mcpu=3Dv7 -mmemorymodel=3Dtso' work for this purpose
 should do it.

Home	PR Database Search