go, branch go1.19.5

[release-branch.go1.19] go1.19.5

2023-01-10T18:15:26Z

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

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

2023-01-09T21:17:08Z

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 #57706. 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/+/461175 Reviewed-by: Ian Lance Taylor Reviewed-by: Heschi Kreinick Reviewed-by: Carlos Amedee

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

2023-01-09T17:35:28Z

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 459178 (commit 91bc4cd118dd). Fixes #57690. Change-Id: Ieb38d9bc7f967e9a726429eab2ea515d5ca0847f Reviewed-on: https://go-review.googlesource.com/c/go/+/461115 Run-TryBot: Russ Cox Reviewed-by: Ian Lance Taylor TryBot-Result: Gopher Robot Reviewed-by: Cherry Mui

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

2023-01-06T17:52:33Z

On macOS return the error code from SecTrustEvaluateWithError, and use it to create typed errors that can be returned from Verify. Updates #56891 Fixes #57427 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/+/460895 Run-TryBot: Filippo Valsorda Reviewed-by: Heschi Kreinick Auto-Submit: Heschi Kreinick Reviewed-by: Carlos Amedee

[release-branch.go1.19] crypto/x509: reallow duplicate attributes in CSRs

2023-01-04T22:23:56Z

Fixes #57556 Updates #54936 Change-Id: I3fb4331c2b1b6adafbac3e76eaf66c79cd5ef56f Reviewed-on: https://go-review.googlesource.com/c/go/+/428636 Run-TryBot: Roland Shoemaker Reviewed-by: Damien Neil TryBot-Result: Gopher Robot Reviewed-by: Roland Shoemaker Auto-Submit: Roland Shoemaker (cherry picked from commit 56d18207823d6e1c18ca46409180c40ae800230c) Reviewed-on: https://go-review.googlesource.com/c/go/+/460236 Reviewed-by: Filippo Valsorda Auto-Submit: Heschi Kreinick Reviewed-by: Heschi Kreinick Reviewed-by: Bryan Mills Run-TryBot: Filippo Valsorda

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

2022-12-28T22:16:43Z

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 #57345 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/+/458355 Run-TryBot: David Chase Auto-Submit: Dmitri Shuralyov

[release-branch.go1.19] cmd/link: recognize the new R_LARCH_32_PCREL type on loong64

2022-12-28T16:57:28Z

This is a minimum backport of CL 420983 without an API change in debug/elf. Original CL description: Due to the latest binutils change [1], at least for certain 32-bit relocs in .eh_frame section, this new type of relocation record is emitted, leading to breakage on systems with bleeding-edge toolchain when trying to link with object(s) with such new-style relocs. Simply treating it the same as the existing reloc types seems enough. Updates #54222. Fixes #57444. [1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f09482a8747b6fd4c2d59a6a64677d3a3fe1e092 Change-Id: Idd86294a11c1d13b88acbca59e537656a57d8109 Reviewed-on: https://go-review.googlesource.com/c/go/+/458836 Reviewed-by: WANG Xuerui Auto-Submit: Dmitri Shuralyov Reviewed-by: David Chase TryBot-Result: Gopher Robot Run-TryBot: Cherry Mui

[release-branch.go1.19] cmd/compile: fix broken IR for iface -> eface

2022-12-28T16:11:17Z

For implementing interface to empty interface conversion, the compiler generate code like: var res *uint8 res = itab if res != nil { res = res.type } However, itab has type *uintptr, so the assignment is broken. The problem is not shown up, until CL 450215, which call typecheck on this broken assignment. To fix this, just cast itab to *uint8 when doing the conversion. Fixes #56770 Change-Id: Id42792d18e7f382578b40854d46eecd49673792c Reviewed-on: https://go-review.googlesource.com/c/go/+/451256 Reviewed-by: Keith Randall TryBot-Result: Gopher Robot Run-TryBot: Cuong Manh Le Reviewed-by: Keith Randall Reviewed-by: Matthew Dempsky Auto-Submit: Cuong Manh Le Reviewed-on: https://go-review.googlesource.com/c/go/+/451875 Auto-Submit: Dmitri Shuralyov Reviewed-by: Joedian Reid

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

2022-12-22T19:21:53Z

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 #56837. 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/+/459178

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

2022-12-21T19:09:19Z

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 #57339 Change-Id: I6680cb54dd4d3514a6887dda8906e6708c64459d Reviewed-on: https://go-review.googlesource.com/c/go/+/457996 Reviewed-by: David Chase Reviewed-by: Brad Fitzpatrick Reviewed-by: Ian Lance Taylor Run-TryBot: Ian Lance Taylor Reviewed-by: Than McIntosh Auto-Submit: Ian Lance Taylor TryBot-Result: Gopher Robot