go/src/runtime/sys_darwin_amd64.s, branch json-isValidNumber-before

runtime: use explicit NOFRAME on darwin/amd64

2023-01-26T07:17:26Z

This CL marks some darwin assembly functions as NOFRAME to avoid relying on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions without stack were also marked as NOFRAME. Change-Id: I797f3909bcf7f7aad304e4ede820c884231e54f6 Reviewed-on: https://go-review.googlesource.com/c/go/+/460235 Reviewed-by: Cherry Mui Run-TryBot: Cherry Mui TryBot-Result: Gopher Robot Reviewed-by: Matthew Dempsky

cmd/link, runtime: Apple libc atfork workaround take 3

2023-01-10T20:34:22Z

CL 451735 worked around bugs in Apple's atfork handlers by calling notify_is_valid_token and xpc_atfork_child at startup, so that init code that wouldn't be safe in the child process would be warmed up in the parent process instead, but xpc_atfork_child broke use of the xpc library in Go programs, and xpc is internally used by various macOS frameworks (#57263). CL 459175 reverted that change, and then CL 459176 tried a new approach: use __fork, which doesn't call any of the atfork handlers at all. That worked, but an Apple engineer reviewing the change in private email suggests that since __fork is not public API, it should be avoided. The same engineer (with access to the source code for the xpc library) suggests that the breakage in #57263 is caused by xpc_atfork_child marking the library as unusable, expecting an imminent call to exec, and that calling xpc_date_create_from_current instead would do the necessary initialization without marking xpc as unusable. CL 460475 reverted that change, to prepare for this one. This CL goes back to the original “call functions to warm things up” approach, replacing xpc_atfork_child with xpc_date_create_from_current. The CL also updates cmd/link to use OS and SDK version 10.13.0 for x86 macOS binaries, up from 10.9.0, also suggested by the Apple engineer. Combined with the two warmup calls, this makes the fork hangs go away. The minimum macOS version has been 10.13 High Sierra since Go 1.17, so there should be no problem with writing that in the binaries too. Fixes #33565. Fixes #56784. Fixes #57263. Fixes #57577. Change-Id: I20769d9daa1fe9ea930f8009481335f8a14dc21b Reviewed-on: https://go-review.googlesource.com/c/go/+/460476 Auto-Submit: Russ Cox Run-TryBot: Russ Cox TryBot-Result: Gopher Robot Reviewed-by: Bryan Mills Reviewed-by: Cherry Mui

runtime: revert Apple libc atfork workaround

2022-12-22T18:03:58Z

Revert CL 451735 (1f4394a0c926), which fixed #33565 and #56784 but also introduced #57263. I have a different fix to apply instead. Since the first fix was never backported, it will be easiest to backport the new fix if the new fix is done in a separate CL from the revert. Change-Id: I6c8ea3a46e542ee4702675bbc058e29ccd2723e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/459175 Reviewed-by: Cherry Mui TryBot-Result: Gopher Robot Run-TryBot: Russ Cox

runtime: work around Apple libc bugs to make exec stop hanging

2022-11-17T21:15:36Z

For a while now, we've had intermittent reports about problems with os/exec on macOS, but no clear way to reproduce them. Recent changes in the os/exec package test seem to have aligned the stars just right, at least on my two x86 and ARM MacBook Pro laptops, to make the package test hang with roughly 50% probability. When it does hang, the stacks I see in the hung process match the ones reported for the Go-based hangs in #33565. (They do not match the ones reported in the so-called C reproducer in that issue, but I think that reproducer is actually reproducing a different race, between fork and exit.) The stacks obtained from the hung child processes are in libSystem_atfork_child, which is supposed to reinitialize various parts of the C library in the new process. One common stack dies in _notify_fork_child calling _notify_globals (inlined) calling _os_alloc_once, because _os_alloc_once detects that the once lock is held by the parent process and then calls _os_once_gate_corruption_abort. The allocation is setting up the globals for the notification subsystem. See the source code at [1]. To work around this, we can allocate the globals earlier in the Go program's lifetime, before any execs are involved, by calling any notify routine that is exported, calls _notify_globals, and doesn't do anything too expensive otherwise. notify_is_valid_token(0) fits the bill. The other common stack dies in xpc_atfork_child calling _objc_msgSend_uncached which ends up in WAITING_FOR_ANOTHER_THREAD_TO_FINISH_CALLING_+initialize. Of course, whatever thread the child is waiting for is in the parent process and is not going to finish anything in the child process. There is no public source code for these routines, so it is unclear exactly what the problem is. However, xpc_atfork_child turns out to be exported (for use by libSystem_atfork_child, which is in a different library, so xpc_atfork_child is unlikely to be unexported any time soon). It also stands to reason that since xpc_atfork_child is called at the start of any forked child process, it can't be too harmful to call at the start of an ordinary Go process. And whatever caches it needs for a non-deadlocking fast path during exec empirically do get initialized by calling it at startup. This CL introduces a function osinit_hack, called at osinit time, which calls notify_is_valid_token(0) and xpc_atfork_child(). Doing so makes the os/exec test pass reliably on both my laptops - I can run it successfully hundreds of times in a row when my previous record was twice in a row. Fixes #33565. Fixes #56784. [1] https://opensource.apple.com/source/Libnotify/Libnotify-241/notify_client.c.auto.html Change-Id: I16a14a800893c40244678203532a3e8d6214b6bd Reviewed-on: https://go-review.googlesource.com/c/go/+/451735 Run-TryBot: Russ Cox Auto-Submit: Russ Cox Reviewed-by: Cherry Mui TryBot-Result: Gopher Robot

net: use libc (not cgo) for DNS on macOS

2022-11-01T14:05:39Z

Change the macOS implementation to use libc calls. Using libc calls directly is what we do for all the runtime and os syscalls. Doing so here as well improves consistency and also makes it possible to cross-compile (from non-Mac systems) macOS binaries that use the native name resolver. Fixes #12524. Change-Id: I011f4fcc5c50fbb5396e494889765dcbb9342336 Reviewed-on: https://go-review.googlesource.com/c/go/+/446178 Run-TryBot: Russ Cox Reviewed-by: Ian Lance Taylor

runtime: mark sigtramp as TOPFRAME on the rest of unix

2022-04-28T23:16:44Z

This extends CL 402190 from Linux to the rest of the Unix OSes. Marking sigtramp as TOPFRAME allows gentraceback to stop tracebacks at the end of a signal handler, since there is not much beyond sigtramp. Change-Id: I8b7f5d55d41889f59c0a79c65351b9b0b2d77717 Reviewed-on: https://go-review.googlesource.com/c/go/+/402934 Reviewed-by: Cherry Mui Reviewed-by: Austin Clements Auto-Submit: Michael Pratt TryBot-Result: Gopher Robot Run-TryBot: Michael Pratt

runtime: use ABIInternal for most calls to sigtrampgo

2022-04-26T18:48:16Z

sigtramp on openbsd-arm64 is teetering on the edge of the nosplit stack limit. Add more headroom by calling sigtrampgo using ABIInternal, which eliminates a 48-byte ABI wrapper frame. openbsd-amd64 has slightly more space, but is also close to the limit, so convert it as well. Other operating systems don't have it as bad, but many have nearly identical implementations of sigtramp, so I have converted them as well. I've omitted darwin-arm64 and solaris, as those are quite different and would benefit from not needing ifdef for both cases. For #51485. Change-Id: I70512645d4208b346a59d5e5d03836a45833b1d7 Reviewed-on: https://go-review.googlesource.com/c/go/+/390814 Run-TryBot: Michael Pratt TryBot-Result: Gopher Robot Reviewed-by: Cherry Mui

crypto/x509, runtime: fix occasional spurious “certificate is expired”

2022-02-22T15:23:59Z

As documented in #51209, we have been seeing a low-rate failure on macOS builders caused by spurious x509 “certificate is expired” errors. The root cause is that CFDateCreate takes a float64, but it is being passed a uintptr instead. That is, we're not even putting CFDateCreate's argument in the right register during the call. Luckily, having just computed the argument by calling time.Duration.Seconds, which returns a float64, most of the time the argument we want is still in the right floating point register, somewhat accidentally. The only time the lucky accident doesn't happen is when the goroutine is rescheduled between calling time.Duration.Seconds and calling into CFDateCreate *and* the rescheduling smashes the floating point register, which can happen during various block memory moves, since the floating point registers are also the SIMD registers. Passing the float64 through explicitly eliminates the problem. It is difficult to write a test for this that is suitable for inclusion in the standard library. We will have to rely on the builders to start flaking again if somehow this problem is reintroduced. For future reference, there is a standalone test that used to fail every few seconds at https://go.dev/play/p/OWfDpxgnW9g. Fixes #51209. Change-Id: I8b334a51e41f406b13f37270e9175c64fe6f55ea Reviewed-on: https://go-review.googlesource.com/c/go/+/387255 Trust: Russ Cox Run-TryBot: Russ Cox Reviewed-by: David Chase Reviewed-by: Cherry Mui TryBot-Result: Gopher Robot

runtime: use per-thread profiler for SetCgoTraceback platforms

2021-09-27T18:58:41Z

Updates #35057 Change-Id: I61d772a2cbfb27540fb70c14676c68593076ca94 Reviewed-on: https://go-review.googlesource.com/c/go/+/342054 Run-TryBot: Rhys Hiltner TryBot-Result: Go Bot Reviewed-by: Michael Pratt Trust: Michael Knyszek

runtime: use abi.FuncPCABI0 for libc syscall wrappers

2021-04-26T18:44:31Z

In CL 288092 we made Darwin syscall wrappers as ABIInternal, so their addresses taken from Go using funcPC are the actual function entries, not the wrappers. As we introduced internal/abi.FuncPCABIxxx intrinsics, use that. And change the assembly functions back to ABI0. Change-Id: I50645af74883e2d5dfcd67a5e8c739222c6f645b Reviewed-on: https://go-review.googlesource.com/c/go/+/313250 Trust: Cherry Zhang Reviewed-by: Michael Knyszek