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.
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.