(Until it can be made hermetic.)

The gopkg.in service has had a lot of flakiness lately. Go users in
general are isolated from that flakiness by the Go module mirror
(proxy.golang.org), but this test intentionally bypasses the module
mirror because the mirror itself uses cmd/go to download the module.

In the long term, we can redirect the gopkg.in URL to the local
(in-process) vcweb server added for #27494.

In the meantime, let's skip the test to reduce the impact of upstream
outages.

Fixes #57057.
Updates #54503.

Change-Id: Icf3de7ca416db548e53864a71776fe22b444fcea
Reviewed-on: https://go-review.googlesource.com/c/go/+/454503
Run-TryBot: Bryan Mills <[email protected]>
Auto-Submit: Bryan Mills <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
Reviewed-by: Heschi Kreinick <[email protected]>
(cherry picked from commit c5f5cb659adda026d01b7fa9bd39b2ad3b58c5bf)
Reviewed-on: https://go-review.googlesource.com/c/go/+/454840

…e.com

TestLookupDotsWithRemoteSource and TestLookupGoogleSRV
were disabled because they look up the no-longer-present
SRV record for _xmpp-server._tcp.google.com.

Change the tests to look for _ldap._tcp.google.com and
reenable them.

For #56708.
Fixes #56711.

Change-Id: I26475fa3ff6fc008048a4e5f24f0e96ee12f655c
Reviewed-on: https://go-review.googlesource.com/c/go/+/453861
Run-TryBot: Damien Neil <[email protected]>
Reviewed-by: Michael Knyszek <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
(cherry picked from commit cb42bbddeb80ff08599079ee6b94088e5be88e5b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/454295
Auto-Submit: Damien Neil <[email protected]>
Reviewed-by: Jenny Rakoczy <[email protected]>

…t_gpg

This was a regression test added for a 'git' command line
used for build stamping. Unfortunately, 'gpg' has proved to
be extremely fragile:

* In recent versions, it appears to always require 'gpg-agent' to be
  installed for anything involving secret keys, but for some reason is
  not normally marked as requiring gpg-agent in Debian's package
  manager.

* It tries to create a Unix domain socket in a subdirectory of $TMPDIR
  without checking the path length, which fails when $TMPDIR is too
  long to fit in the 'sun_path' field of a sockaddr_un struct (which
  typically tops out somewhere between 92 and 108 bytes).

We could theoretically address those by artificially reducing the
script's TMPDIR length and checking for gpg-agent in addition to gpg,
but arguably those should both be fixed upstream instead. On balance,
the incremental value that this test provides does not seem worth the
complexity of dealing with such a fragile third-party tool.

Updates #50675.
Updates #48802.
Updates #57034.
Fixes #57054.

Change-Id: Ia3288c2f84f8db86ddfa139b4d1c0112d67079ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/454502
TryBot-Result: Gopher Robot <[email protected]>
Run-TryBot: Bryan Mills <[email protected]>
Auto-Submit: Bryan Mills <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
(cherry picked from commit 45f5ef4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/454956

… distance calculation

If a compatible trampoline has been inserted by a previously laid
function in the same section, and is known to be sufficiently close,
it can be reused.

When testing if the trampoline can be reused, the addend of the direct
call should be ignored. It is already encoded in the trampoline. If the
addend is non-zero, and the target sufficiently far away, and just
beyond direct call reach, this may cause the trampoline to be
incorrectly reused.

This was observed on go1.17.13 and openshift-installer commit f3c53b382
building in release mode with the following error:

github.com/aliyun/alibaba-cloud-sdk-go/services/cms.(*Client).DescribeMonitoringAgentAccessKeyWithChan.func1: direct call too far: runtime.duffzero+1f0-tramp0-1 -2000078

Fixes #56833

Change-Id: I54af957302506d4e3cd5d3121542c83fe980e912
Reviewed-on: https://go-review.googlesource.com/c/go/+/451415
Reviewed-by: Cherry Mui <[email protected]>
Run-TryBot: Paul Murphy <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
Reviewed-by: Lynn Boger <[email protected]>
Reviewed-by: Than McIntosh <[email protected]>
Reviewed-on: https://go-review.googlesource.com/c/go/+/451916
Reviewed-by: Joedian Reid <[email protected]>

…s a symlink

Tested by temporarily changing sysdir to use a directory where
the expected files were all symlinks. We should consider using
a different approach that doesn't rely on sysdir, but for now
do a minimal fix.

For #57210
Fixes #57213

Change-Id: Ifb1becef03e014ceb48290ce13527b3e103c0e07
Reviewed-on: https://go-review.googlesource.com/c/go/+/456557
Reviewed-by: Ian Lance Taylor <[email protected]>
Reviewed-by: Bryan Mills <[email protected]>
Run-TryBot: Ian Lance Taylor <[email protected]>
Auto-Submit: Ian Lance Taylor <[email protected]>
Run-TryBot: Ian Lance Taylor <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
(cherry picked from commit 9b8750f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/456561
Reviewed-by: Austin Clements <[email protected]>

…214163811-6143a133e5c9

Update x/net to include the fix for #53960.

For #53960
For #56323

Change-Id: I825212ecdf7bf2f52c2fda1faf1739b593063653
Reviewed-on: https://go-review.googlesource.com/c/go/+/457596
TryBot-Result: Gopher Robot <[email protected]>
Reviewed-by: Than McIntosh <[email protected]>
Run-TryBot: Damien Neil <[email protected]>

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 <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
Reviewed-by: Keith Randall <[email protected]>
Run-TryBot: Keith Randall <[email protected]>
Reviewed-on: https://go-review.googlesource.com/c/go/+/456558
Reviewed-by: Than McIntosh <[email protected]>

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 <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
Reviewed-by: Keith Randall <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
Reviewed-by: KAMPANAT THUMWONG (KONG PC) <[email protected]>
Run-TryBot: Archana Ravindar <[email protected]>
Reviewed-on: https://go-review.googlesource.com/c/go/+/456735
Reviewed-by: Than McIntosh <[email protected]>

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 <[email protected]>
Run-TryBot: Ian Lance Taylor <[email protected]>
Auto-Submit: Ian Lance Taylor <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
(cherry picked from commit e66f895)

Change-Id: I2cf063160508687067c7672cef0517bccd707d7b
GitHub-Last-Rev: 32208e4
GitHub-Pull-Request: #57067
Reviewed-on: https://go-review.googlesource.com/c/go/+/455055
Reviewed-by: Ian Lance Taylor <[email protected]>
Run-TryBot: David Chase <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>

…n linux-arm

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 <[email protected]>
Run-TryBot: Ian Lance Taylor <[email protected]>
Reviewed-by: Than McIntosh <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
Reviewed-by: Brad Fitzpatrick <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
Reviewed-by: David Chase <[email protected]>
Auto-Submit: Ian Lance Taylor <[email protected]>
Run-TryBot: Ian Lance Taylor <[email protected]>

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 <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
Run-TryBot: Russ Cox <[email protected]>
Reviewed-on: https://go-review.googlesource.com/c/go/+/459179

…the LoweredAtomicCas32 on mips64x,riscv64

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 <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
Reviewed-by: Matthew Dempsky <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
Reviewed-by: Wayne Zuo <[email protected]>
Reviewed-by: Than McIntosh <[email protected]>
Reviewed-by: David Chase <[email protected]>
Reviewed-on: https://go-review.googlesource.com/c/go/+/458357
Run-TryBot: David Chase <[email protected]>
Auto-Submit: Dmitri Shuralyov <[email protected]>

… on macOS

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 <[email protected]>
Reviewed-by: Filippo Valsorda <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
(cherry picked from commit c9a10d4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/460896
Reviewed-by: Carlos Amedee <[email protected]>
Auto-Submit: Heschi Kreinick <[email protected]>
Reviewed-by: Heschi Kreinick <[email protected]>
Run-TryBot: Filippo Valsorda <[email protected]>

…on darwin"

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 07b6ffb).

Fixes #57689.

Change-Id: I3b81de6bded399f47862325129e86a65c83d8e3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/461116
Reviewed-by: Ian Lance Taylor <[email protected]>
Run-TryBot: Russ Cox <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>

…ol path

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 <[email protected]>
Reviewed-by: Bryan Mills <[email protected]>
Run-TryBot: Than McIntosh <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
(cherry picked from commit 771a98d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/461176
Reviewed-by: Heschi Kreinick <[email protected]>
Reviewed-by: Carlos Amedee <[email protected]>

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