go, branch go1.18.10

[release-branch.go1.18] go1.18.10

2023-01-10T18:17:59Z

Change-Id: I8cc4645d07defe595f3bf00eedb989a5edc5b3b7 Reviewed-on: https://go-review.googlesource.com/c/go/+/461357 TryBot-Result: Gopher Robot Reviewed-by: Carlos Amedee Run-TryBot: Gopher Robot Reviewed-by: Heschi Kreinick Auto-Submit: Gopher Robot

[release-branch.go1.18] misc/cgo/testcshared: handle unsuffixed dlltool path

2023-01-09T21:17:14Z

Adapt the testcshared tests to handle the case where the path output by invoking gcc -print-prog-name=dlltool is a path lacking the final ".exe" suffix (this seems to be what clang is doing); tack it on before using if this is the case. Updates #57704. Fixes #57705. Change-Id: I04fb7b9fc90677880b1ced4a4ad2a8867a3f5f86 Reviewed-on: https://go-review.googlesource.com/c/go/+/451816 TryBot-Result: Gopher Robot Reviewed-by: Bryan Mills Run-TryBot: Than McIntosh Reviewed-by: Cherry Mui (cherry picked from commit 771a98d6b19c9ca4bbd3fbeba03d7d512f77c166) Reviewed-on: https://go-review.googlesource.com/c/go/+/461176 Reviewed-by: Heschi Kreinick Reviewed-by: Carlos Amedee

[release-branch.go1.18] runtime: revert "call __fork instead of fork on darwin"

2023-01-09T17:35:17Z

A recent comment on #57263 reports an unexplained crash in a cgo program that is fixed by reverting the __fork fix. We don't have any viable fix for the os/exec bug at this point, so give up on a fix for the January point releases. This reverts CL 459179 (commit 07b6ffb79c90). Fixes #57689. Change-Id: I3b81de6bded399f47862325129e86a65c83d8e3b Reviewed-on: https://go-review.googlesource.com/c/go/+/461116 Reviewed-by: Ian Lance Taylor Run-TryBot: Russ Cox TryBot-Result: Gopher Robot Reviewed-by: Cherry Mui

[release-branch.go1.18] crypto/x509: return typed verification errors on macOS

2023-01-06T17:52:13Z

On macOS return the error code from SecTrustEvaluateWithError, and use it to create typed errors that can be returned from Verify. Updates #56891 Fixes #57426 Change-Id: Ib597ce202abb60702f730e75da583894422e4c14 Reviewed-on: https://go-review.googlesource.com/c/go/+/452620 Run-TryBot: Roland Shoemaker Reviewed-by: Filippo Valsorda TryBot-Result: Gopher Robot Reviewed-by: Dmitri Shuralyov (cherry picked from commit c9a10d48a8f0e8479f5b9d98c5bd81b64a90d23d) Reviewed-on: https://go-review.googlesource.com/c/go/+/460896 Reviewed-by: Carlos Amedee Auto-Submit: Heschi Kreinick Reviewed-by: Heschi Kreinick Run-TryBot: Filippo Valsorda

[release-branch.go1.18] cmd/compile: sign-extend the 2nd argument of the LoweredAtomicCas32 on mips64x,riscv64

2022-12-28T22:17:03Z

The function LoweredAtomicCas32 is implemented using the LL-SC instruction pair on loong64, mips64x, riscv64. However,the LL instruction on loong64, mips64x, riscv64 is sign-extended, so it is necessary to sign-extend the 2nd parameter "old" of the LoweredAtomicCas32, so that the instruction BNE after LL can get the desired result. The function prototype of LoweredAtomicCas32 in golang: func Cas32(ptr *uint32, old, new uint32) bool When using an intrinsify implementation: case 1: (*ptr) <= 0x80000000 && old < 0x80000000 E.g: (*ptr) = 0x7FFFFFFF, old = Rarg1= 0x7FFFFFFF After run the instruction "LL (Rarg0), Rtmp": Rtmp = 0x7FFFFFFF Rtmp ! = Rarg1(old) is false, the result we expect case 2: (*ptr) >= 0x80000000 && old >= 0x80000000 E.g: (*ptr) = 0x80000000, old = Rarg1= 0x80000000 After run the instruction "LL (Rarg0), Rtmp": Rtmp = 0xFFFFFFFF_80000000 Rtmp ! = Rarg1(old) is true, which we do not expect When using an non-intrinsify implementation: Because Rarg1 is loaded from the stack using sign-extended instructions ld.w, the situation described in Case 2 above does not occur Benchmarks on linux/loong64: name old time/op new time/op delta Cas 50.0ns ± 0% 50.1ns ± 0% ~ (p=1.000 n=1+1) Cas64 50.0ns ± 0% 50.1ns ± 0% ~ (p=1.000 n=1+1) Cas-4 56.0ns ± 0% 56.0ns ± 0% ~ (p=1.000 n=1+1) Cas64-4 56.0ns ± 0% 56.0ns ± 0% ~ (p=1.000 n=1+1) Benchmarks on Loongson 3A4000 (GOARCH=mips64le, 1.8GHz) name old time/op new time/op delta Cas 70.4ns ± 0% 70.3ns ± 0% ~ (p=1.000 n=1+1) Cas64 70.7ns ± 0% 70.6ns ± 0% ~ (p=1.000 n=1+1) Cas-4 81.1ns ± 0% 80.8ns ± 0% ~ (p=1.000 n=1+1) Cas64-4 80.9ns ± 0% 80.9ns ± 0% ~ (p=1.000 n=1+1) Fixes #57344 Change-Id: I190a7fc648023b15fa392f7fdda5ac18c1561bac Reviewed-on: https://go-review.googlesource.com/c/go/+/457135 Run-TryBot: Than McIntosh Reviewed-by: Cherry Mui Reviewed-by: Matthew Dempsky TryBot-Result: Gopher Robot Reviewed-by: Wayne Zuo Reviewed-by: Than McIntosh Reviewed-by: David Chase Reviewed-on: https://go-review.googlesource.com/c/go/+/458357 Run-TryBot: David Chase Auto-Submit: Dmitri Shuralyov

[release-branch.go1.18] runtime: call __fork instead of fork on darwin

2022-12-22T19:21:48Z

Issues #33565 and #56784 were caused by hangs in the child process after fork, while it ran atfork handlers that ran into slow paths that didn't work in the child. CL 451735 worked around those two issues by calling a couple functions at startup to try to warm up those child paths. That mostly worked, but it broke programs using cgo with certain macOS frameworks (#57263). CL 459175 reverted CL 451735. This CL introduces a different fix: bypass the atfork child handlers entirely. For a general fork call where the child and parent are both meant to keep executing the original program, atfork handlers can be necessary to fix any state that would otherwise be tied to the parent process. But Go only uses fork as preparation for exec, and it takes care to limit what it attempts to do in the child between the fork and exec. In particular it doesn't use any of the things that the macOS atfork handlers are trying to fix up (malloc, xpc, others). So we can use the low-level fork system call (__fork) instead of the atfork-wrapped one. The full list of functions that can be called in a child after fork in exec_libc2.go is: - ptrace - setsid - setpgid - getpid - ioctl - chroot - setgroups - setgid - setuid - chdir - dup2 - fcntl - close - execve - write - exit I disassembled all of these while attached to a hung exec.test binary and confirmed that nearly all of them are making direct kernel calls, not using anything that the atfork handler needs to fix up. The exceptions are ioctl, fcntl, and exit. The ioctl and fcntl implementations do some extra work around the kernel call but don't call any other functions, so they should still be OK. (If not, we could use __ioctl and __fcntl instead, but without a good reason, we should keep using the standard entry points.) The exit implementation calls atexit handlers. That is almost certainly inappropriate in a failed fork child, so this CL changes that call to __exit on darwin. To avoid making unnecessary changes at this point in the release cycle, this CL leaves OpenBSD calling plain exit, even though that is probably a bug in the OpenBSD port (filed #57446). Fixes #33565. Fixes #56784. Fixes #57263. Fixes #56836. Change-Id: I26812c26a72bdd7fcf72ec41899ba11cf6b9c4ab Reviewed-on: https://go-review.googlesource.com/c/go/+/459176 Reviewed-by: David Chase Reviewed-by: Cherry Mui TryBot-Result: Gopher Robot Run-TryBot: Russ Cox Reviewed-on: https://go-review.googlesource.com/c/go/+/459179

[release-branch.go1.18] syscall, internal/poll: fall back to accept on linux-arm

2022-12-21T19:08:36Z

Our minimum Linux version is 2.6.32, and the accept4 system call was introduced in 2.6.28, so we use accept4 everywhere. Unfortunately, it turns out that the accept4 system call was only added to linux-arm in 2.6.36, so for linux-arm only we need to try the accept4 system call and then fall back to accept if it doesn't work. The code we use on linux-arm is the code we used in Go 1.17. On non-arm platforms we continue using the simpler code introduced in Go 1.18. Adding accept4 to the ARM Linux kernel was: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=21d93e2e29722d7832f61cc56d73fb953ee6578e For #57333 Fixes #57338 Change-Id: I6680cb54dd4d3514a6887dda8906e6708c64459d Reviewed-on: https://go-review.googlesource.com/c/go/+/457997 Reviewed-by: Tobias Klauser Run-TryBot: Ian Lance Taylor Reviewed-by: Than McIntosh Reviewed-by: Ian Lance Taylor Reviewed-by: Brad Fitzpatrick TryBot-Result: Gopher Robot Reviewed-by: David Chase Auto-Submit: Ian Lance Taylor Run-TryBot: Ian Lance Taylor

[release-branch.go1.18] cmd/cgo: allow DW_TAG_variable's with no name

2022-12-19T22:23:40Z

https://reviews.llvm.org/D123534 is emitting DW_TAG_variable's that don't have a DW_AT_name. This is allowed in the DWARF standard. It is adding DIE's for string literals for better symbolization on buffer overlows etc on these strings. They no associated name because they are not user provided variables. Fixes #57044 Updates #53000 Change-Id: I2cf063160508687067c7672cef0517bccd707d7b Reviewed-on: https://go-review.googlesource.com/c/go/+/406816 TryBot-Result: Gopher Robot Run-TryBot: Ian Lance Taylor Auto-Submit: Ian Lance Taylor Reviewed-by: Ian Lance Taylor (cherry picked from commit e66f895667cd51d0d28c42d369a803c12db8bb35) Change-Id: I2cf063160508687067c7672cef0517bccd707d7b GitHub-Last-Rev: 32208e4fa20272b80cfffd95a4701e1473f47ca9 GitHub-Pull-Request: golang/go#57067 Reviewed-on: https://go-review.googlesource.com/c/go/+/455055 Reviewed-by: Ian Lance Taylor Run-TryBot: David Chase TryBot-Result: Gopher Robot

[release-branch.go1.18] cmd/compile: fix conditional move rule on PPC64

2022-12-19T21:46:51Z

Similar to CL 456556 but for ppc64 instead of arm64. Change docs about how booleans are stored in registers for ppc64. We now don't promise to keep the upper bits zeroed; they might be junk. To test, I changed the boolean generation instructions (MOVBZload* and ISEL* with boolean type) to OR in 0x100 to the result. all.bash still passed, so I think nothing else is depending on the upper bits of booleans. Update #57211 Change-Id: Ie66f8934a0dafa34d0a8c2a37324868d959a852c Reviewed-on: https://go-review.googlesource.com/c/go/+/456437 Run-TryBot: Keith Randall Reviewed-by: Cherry Mui Reviewed-by: Keith Randall TryBot-Result: Gopher Robot Reviewed-by: KAMPANAT THUMWONG (KONG PC) <1992kongpc.kth@gmail.com> Run-TryBot: Archana Ravindar Reviewed-on: https://go-review.googlesource.com/c/go/+/456735 Reviewed-by: Than McIntosh

[release-branch.go1.18] cmd/compile: fix conditional select rule

2022-12-19T21:46:43Z

ARM64 maintains booleans in the low byte of registers. Upper parts of that register are junk. This rule is using all 32 bits of a boolean-containing register, which is wrong. Change the rule to only look at the low bit. Fixes #57211 Change-Id: Ibbef86b2be859df3d06d993db00e1231c481c428 Reviewed-on: https://go-review.googlesource.com/c/go/+/456556 Auto-Submit: Keith Randall TryBot-Result: Gopher Robot Reviewed-by: Cherry Mui Reviewed-by: Keith Randall Run-TryBot: Keith Randall Reviewed-on: https://go-review.googlesource.com/c/go/+/456558 Reviewed-by: Than McIntosh