aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/sys_darwin.go
AgeCommit message (Collapse)Author
2025-10-21runtime,syscall: implement and use syscalln on darwinqmuntal
All darwin syscall implementations can be consolidated into a single syscalln function, as already happens on Windows. This reduces duplication and allows moving some logic from runtime to syscall. Updates #699135 Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64-longtest,gotip-darwin-amd64-longtest,x_sys-gotip-darwin-arm64-longtest,x_sys-gotip-darwin-amd64-longtest Change-Id: If5de80442b1d4a1123258401a3ae21695e7c8f6b Reviewed-on: https://go-review.googlesource.com/c/go/+/699177 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-09-15runtime: deduplicate syscall assembly for darwinqmuntal
The darwin port provides different syscall functions that only differ on how they handle the errors, and they are all written in assembly. This duplication can be removed by factoring out the error handling logic to arch-agnostic Go code and leaving the assembly functions with the only reponsibility of making the syscall and mapping parameters between ABIs. Updates #51087 Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64-longtest,gotip-darwin-amd64-longtest Change-Id: I9524377f3ef9c9a638412c7e87c8f46a33ee3453 Reviewed-on: https://go-review.googlesource.com/c/go/+/699135 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-04-15runtime: don't use cgo_unsafe_args for syscall9 wrapperKeith Randall
It uses less stack space this way. Similar to CL 386719 Update #71302 Change-Id: I585bde5f681a90a6900cbd326994ab8a122fd148 Reviewed-on: https://go-review.googlesource.com/c/go/+/665695 Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-10-07runtime: use arc4random_buf() for readRandomFilippo Valsorda
readRandom doesn't matter on Linux because of startupRand, but it does on Windows and macOS. Windows already uses the same API as crypto/rand. Switch macOS away from the /dev/urandom read. Updates #68278 Cq-Include-Trybots: luci.golang.try:gotip-darwin-amd64_14 Change-Id: Ie8f105e35658a6f10ff68798d14883e3b212eb3e Reviewed-on: https://go-review.googlesource.com/c/go/+/608436 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-05-23all: document legacy //go:linkname for modules with ≥200 dependentsRuss Cox
Ignored these linknames which have not worked for a while: github.com/xtls/xray-core: context.newCancelCtx removed in CL 463999 (Feb 2023) github.com/u-root/u-root: funcPC removed in CL 513837 (Jul 2023) tinygo.org/x/drivers: net.useNetdev never existed For #67401. Change-Id: I9293f4ef197bb5552b431de8939fa94988a060ce Reviewed-on: https://go-review.googlesource.com/c/go/+/587576 Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-05-23all: document legacy //go:linkname for modules with ≥1,000 dependentsRuss Cox
For #67401. Change-Id: If23a2c07e3dd042a3c439da7088437a330b9caa4 Reviewed-on: https://go-review.googlesource.com/c/go/+/587222 Auto-Submit: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-05-22all: document legacy //go:linkname for modules with ≥100,000 dependentsRuss Cox
For #67401. Change-Id: I51f5b561ee11eb242e3b1585d591281d0df4fc24 Reviewed-on: https://go-review.googlesource.com/c/go/+/587215 Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-03-25runtime: migrate internal/atomic to internal/runtimeAndy Pan
For #65355 Change-Id: I65dd090fb99de9b231af2112c5ccb0eb635db2be Reviewed-on: https://go-review.googlesource.com/c/go/+/560155 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ibrahim Bazoka <ibrahimbazoka729@gmail.com> Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
2023-08-03runtime,runtime/pprof: get memory mappings on darwin.Cosmos Nicolaou
Displaying assembly language has never worked for Apple Silicon macs (see #50891). This change uses mach_vm_region to obtain the necessary VM mappings to allow for locating assembly instructions for a cpu profile. Fixes #50891 Change-Id: Ib968c55a19b481b82f63337276b552f3b18f69d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/503919 Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2023-06-06runtime: implement SUID/SGID protectionsRoland Shoemaker
On Unix platforms, the runtime previously did nothing special when a program was run with either the SUID or SGID bits set. This can be dangerous in certain cases, such as when dumping memory state, or assuming the status of standard i/o file descriptors. Taking cues from glibc, this change implements a set of protections when a binary is run with SUID or SGID bits set (or is SUID/SGID-like). On Linux, whether to enable these protections is determined by whether the AT_SECURE flag is passed in the auxiliary vector. On platforms which have the issetugid syscall (the BSDs, darwin, and Solaris/Illumos), that is used. On the remaining platforms (currently only AIX) we check !(getuid() == geteuid() && getgid == getegid()). Currently when we determine a binary is "tainted" (using the glibc terminology), we implement two specific protections: 1. we check if the file descriptors 0, 1, and 2 are open, and if they are not, we open them, pointing at /dev/null (or fail). 2. we force GOTRACKBACK=none, and generally prevent dumping of trackbacks and registers when a program panics/aborts. In the future we may add additional protections. This change requires implementing issetugid on the platforms which support it, and implementing getuid, geteuid, getgid, and getegid on AIX. Thanks to Vincent Dehors from Synacktiv for reporting this issue. Fixes #60272 Fixes CVE-2023-29403 Change-Id: I73fc93f2b7a8933c192ce3eabbf1db359db7d5fa Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1878434 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Russ Cox <rsc@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/501223 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-05-20runtime: consolidate on a single closeonexec definitionIan Lance Taylor
Now that we implement fcntl on all Unix systems, we can write closeonexec that uses it. This lets us remove a bunch of assembler code. Change-Id: If35591df535ccfc67292086a9492f0a8920e3681 Reviewed-on: https://go-review.googlesource.com/c/go/+/496081 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2023-05-20runtime: change fcntl to return two valuesIan Lance Taylor
Separate the result and the errno value, rather than assuming that the result can never be negative. Change-Id: Ib01a70a3d46285aa77e95371cdde74e1504e7c12 Reviewed-on: https://go-review.googlesource.com/c/go/+/496416 Run-TryBot: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2023-02-10runtime: skip darwin osinit_hack on iosRuss Cox
Darwin needs the osinit_hack call to fix some bugs in the Apple libc that surface when Go programs call exec. On iOS, the functions that osinit_hack uses are not available, so signing fails. But on iOS exec is also unavailable, so the hack is not needed. Disable it there, which makes signing work again. Fixes #58323. Change-Id: I3f1472f852bb36c06854fe1f14aa27ad450c5945 Reviewed-on: https://go-review.googlesource.com/c/go/+/466516 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Dave Anderson <danderson@tailscale.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2023-01-10cmd/link, runtime: Apple libc atfork workaround take 3Russ Cox
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 <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2022-12-22runtime: revert Apple libc atfork workaroundRuss Cox
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 <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>
2022-11-17runtime: work around Apple libc bugs to make exec stop hangingRuss Cox
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 <rsc@golang.org> Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-11-01net: use libc (not cgo) for DNS on macOSRuss Cox
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 <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
2022-10-18runtime: throw in unreachable exitThreadMichael Pratt
Several OSes don't ever reach exitThread, On AIX, Plan9, Solaris, and Windows, we throw if this function is accidentally reached. Do the same on Darwin and OpenBSD for consistency. Change-Id: Icd189b11179755a28b3ec48b267349c57facbf24 Reviewed-on: https://go-review.googlesource.com/c/go/+/443717 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Pratt <mpratt@google.com>
2022-10-18runtime: always keep global reference to mp until mexit completesMichael Pratt
Ms are allocated via standard heap allocation (`new(m)`), which means we must keep them alive (i.e., reachable by the GC) until we are completely done using them. Ms are primarily reachable through runtime.allm. However, runtime.mexit drops the M from allm fairly early, long before it is done using the M structure. If that was the last reference to the M, it is now at risk of being freed by the GC and used for some other allocation, leading to memory corruption. Ms with a Go-allocated stack coincidentally already keep a reference to the M in sched.freem, so that the stack can be freed lazily. This reference has the side effect of keeping this Ms reachable. However, Ms with an OS stack skip this and are at risk of corruption. Fix this lifetime by extending sched.freem use to all Ms, with the value of mp.freeWait determining whether the stack needs to be freed or not. Fixes #56243. Change-Id: Ic0c01684775f5646970df507111c9abaac0ba52e Reviewed-on: https://go-review.googlesource.com/c/go/+/443716 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2022-04-11all: gofmt main repoRuss Cox
[This CL is part of a sequence implementing the proposal #51082. The design doc is at https://go.dev/s/godocfmt-design.] Run the updated gofmt, which reformats doc comments, on the main repository. Vendored files are excluded. For #51082. Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407 Reviewed-on: https://go-review.googlesource.com/c/go/+/384268 Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2022-04-05all: separate doc comment from //go: directivesRuss Cox
A future change to gofmt will rewrite // Doc comment. //go:foo to // Doc comment. // //go:foo Apply that change preemptively to all comments (not necessarily just doc comments). For #51082. Change-Id: Iffe0285418d1e79d34526af3520b415a12203ca9 Reviewed-on: https://go-review.googlesource.com/c/go/+/384260 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-02-28runtime: avoid cgo_unsafe_args for syscall.syscall functions on darwin/arm64Cherry Mui
Currently, syscall.syscall-like functions are defined as cgo_unsafe_args, which makes them ABI0, as it takes the address of the argument area based on ABI0 layout. Those functions are linkname'd to the syscall package. When compiling the syscall package, the compiler doesn't know they are ABI0 therefore generate an ABIInternal call, which will use the wrapper. As some of the functions (e.g. syscall6) has many arguments, the wrapper would take a good amount of stack space. And those functions must be nosplit. This causes nosplit overflow when building with -N -l and -race. Avoid that by rewriting the functions to not use cgo_unsafe_args. Instead, make a struct locally and pass the address of that struct. This way the functions are ABIInternal and the call will not use the wrapper. Fixes #51247. Change-Id: I76c1ab86b9d28664fa7d5b9c7928fbb2fd8d1417 Reviewed-on: https://go-review.googlesource.com/c/go/+/386719 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2022-02-22crypto/x509, runtime: fix occasional spurious “certificate is expired”Russ Cox
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 <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-11-30runtime: keep //go:cgo_unsafe_args arguments alive to prevent GCJason A. Donenfeld
When syscall's DLL.FindProc calls into syscall_getprocaddress with a byte slice pointer, we need to keep those bytes alive. Otherwise the GC will collect the allocation, and we wind up calling `GetProcAddress` on garbage, which showed up as various flakes in the builders. It turns out that this problem extends to many uses of //go:cgo_unsafe_args throughout, on all platforms. So this patch fixes the issue by keeping non-integer pointer arguments alive through their invocation in //go:cgo_unsafe_args functions. Fixes #49731. Change-Id: I93e4fbc2e8e210cb3fc53149708758bb33f2f9c7 Reviewed-on: https://go-review.googlesource.com/c/go/+/367654 Trust: Jason A. Donenfeld <Jason@zx2c4.com> Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Patrik Nyblom <pnyb@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-11-10runtime: fix unworkable comments for go:nosplitHajime Hoshi
Change-Id: I71c29a2dc7e5b2b6bc35093535228d2907b16b47 Reviewed-on: https://go-review.googlesource.com/c/go/+/361595 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Hajime Hoshi <hajimehoshi@gmail.com>
2021-04-29runtime: rename walltime1 to walltimeIan Lance Taylor
Change-Id: Iec9de5ca56eb68d524bbaa0668515dbd09ad38a1 Reviewed-on: https://go-review.googlesource.com/c/go/+/314770 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-04-26runtime: use abi.FuncPCABI0 for libc syscall wrappersCherry Zhang
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 <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-03-01runtime: use entersyscall in syscall_syscallX on DarwinCherry Zhang
CL 197938 changed syscall* functions to call entersyscall, instead of entersyscallblock. It missed syscall_syscallX, probably because it was in sys_darwin_64.go, not sys_darwin.go like others. Change that one as well. Found during the review of CL 270380 (thanks Joel). Change-Id: I0884fc766703f555a3895be332dccfa7d2431374 Reviewed-on: https://go-review.googlesource.com/c/go/+/286435 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-02-19runtime: clean up system calls during cgo callback initRuss Cox
During a cgocallback, the runtime calls needm to get an m. The calls made during needm cannot themselves assume that there is an m or a g (which is attached to the m). In the old days of making direct system calls, the only thing you had to do for such functions was mark them //go:nosplit, to avoid the use of g in the stack split prologue. But now, on operating systems that make system calls through shared libraries and use code that saves state in the g or m before doing so, it's not safe to assume g exists. In fact, it is not even safe to call getg(), because it might fault deferencing the TLS storage to find the g pointer (that storage may not be initialized yet, at least on Windows, and perhaps on other systems in the future). The specific routines that are problematic are usleep and osyield, which are called during lock contention in lockextra, called from needm. All this is rather subtle and hidden, so in addition to fixing the problem on Windows, this CL makes the fact of not running on a g much clearer by introducing variants usleep_no_g and osyield_no_g whose names should make clear that there is no g. And then we can remove the various sketchy getg() == nil checks in the existing routines. As part of this cleanup, this CL also deletes onosstack on Windows. onosstack is from back when the runtime was implemented in C. It predates systemstack but does essentially the same thing. Instead of having two different copies of this code, we can use systemstack consistently. This way we need not port onosstack to each architecture. This CL is part of a stack adding windows/arm64 support (#36439), intended to land in the Go 1.17 cycle. This CL is, however, not windows/arm64-specific. It is cleanup meant to make the port (and future ports) easier. Change-Id: I3352de1fd0a3c26267c6e209063e6e86abd26187 Reviewed-on: https://go-review.googlesource.com/c/go/+/288793 Trust: Russ Cox <rsc@golang.org> Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
2021-01-19cmd/link,runtime: switch openbsd/amd64 to pthreadsJoel Sing
This switches openbsd/amd64 to thread creation via pthreads, rather than doing direct system calls. Update #36435 Change-Id: I1105d5c392aa3e4c445d99c8cb80b927712e3529 Reviewed-on: https://go-review.googlesource.com/c/go/+/250180 Trust: Joel Sing <joel@sing.id.au> Run-TryBot: Joel Sing <joel@sing.id.au> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-12-21runtime: use _exit on darwinCherry Zhang
On darwin, where we use libc for syscalls, when the runtime exits, it calls libc exit function, which may call back into user code, e.g. invoking functions registered with atexit. In particular, it may call back into Go. But at this point, the Go runtime is already exiting, so this wouldn't work. On non-libc platforms we use exit syscall directly, which doesn't invoke any callbacks. Use _exit on darwin to achieve the same behavior. No test for now, as it doesn't pass on all platforms (see trybot run of PS2). May fix #42465. May fix #43294. Change-Id: Ia1ada22b5da8cb64fdd598d0541eb90e195367eb Reviewed-on: https://go-review.googlesource.com/c/go/+/269378 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-12-07internal/cpu: add darwin/arm64 CPU feature detection supportMartin Möhrmann
Fixes #42747 Change-Id: I6b1679348c77161f075f0678818bb003fc0e8c86 Reviewed-on: https://go-review.googlesource.com/c/go/+/271989 Trust: Martin Möhrmann <moehrmann@google.com> Run-TryBot: Martin Möhrmann <martisch@uos.de> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-11-30runtime: mlock signal stack on macOS/ARM64Cherry Zhang
Apparently, the macOS ARM64 kernel has a bug where when a signal arrives and the signal stack is not currently faulted in, it may kill the program with a SIGILL. Work around it by mlock the signal stacks. Fixes #42774. Change-Id: I99a4b3fdb6d8af1c945725ddc2c25568d81c510a Reviewed-on: https://go-review.googlesource.com/c/go/+/273686 Trust: Cherry Zhang <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2020-11-18runtime: use clock_gettime instead of gettimeofday on darwinTobias Klauser
clock_gettime has higher resolution than gettimeofday and is available since macOS 10.12. Go 1.15 already requires at least macOS 10.12 and thus clock_gettime can be used unconditionally (also see https://golang.org/doc/go1.15#darwin) Fixes #25633 Change-Id: I46305387212735e5d3a13e5f02ec90f3e6d546a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/270918 Trust: Tobias Klauser <tobias.klauser@gmail.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-08-17cmd/link: link dynamic library automaticallyCherry Zhang
cgo_import_dynamic pragma indicates a symbol is imported from a dynamic library. Currently, the linker does not actually link against the dynamic library, so we have to "force" it by using //go:cgo_import_dynamic _ _ "dylib" syntax, which links in the library unconditionally. This CL changes it to link in the library automatically when a symbol is imported from the library, without using the "force" syntax. (The "force" syntax is still supported.) Remove the unconditional imports in the runtime. Now, Security.framework and CoreFoundation.framework are only linked when the x509 package is imported (or otherwise specified). Fixes #40727. Change-Id: Ied36b1f621cdcc5dc4a8f497cdf1c554a182d0e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/248333 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-07-08crypto/x509/internal/macos: rename package to lowercaseFilippo Valsorda
Also add a test to lock in this policy. Fixes #40065 Change-Id: Iedc4586f2f5598046d84132a8f3bba8f2e93ddc2 Reviewed-on: https://go-review.googlesource.com/c/go/+/241274 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-05-07crypto/x509: use Security.framework without cgo for roots on macOSFilippo Valsorda
+----------------------------------------------------------------------+ | Hello, if you are reading this and run macOS, please test this code: | | | | $ GO111MODULE=on go get golang.org/dl/gotip@latest | | $ gotip download | | $ GODEBUG=x509roots=1 gotip test crypto/x509 -v -run TestSystemRoots | +----------------------------------------------------------------------+ We currently have two code paths to extract system roots on macOS: one uses cgo to invoke a maze of Security.framework APIs; the other is a horrible fallback that runs "/usr/bin/security verify-cert" on every root that has custom policies to check if it's trusted for SSL. The fallback is not only terrifying because it shells out to a binary, but also because it lets in certificates that are not trusted roots but are signed by trusted roots, and because it applies some filters (EKUs and expiration) only to roots with custom policies, as the others are not passed to verify-cert. The other code path, of course, requires cgo, so can't be used when cross-compiling and involves a large ball of C. It's all a mess, and it broke oh-so-many times (#14514, #16532, #19436, #20990, #21416, #24437, #24652, #25649, #26073, #27958, #28025, #28092, #29497, #30471, #30672, #30763, #30889, #32891, #38215, #38365, ...). Since macOS does not have a stable syscall ABI, we already dynamically link and invoke libSystem.dylib regardless of cgo availability (#17490). How that works is that functions in package syscall (like syscall.Open) take the address of assembly trampolines (like libc_open_trampoline) that jump to symbols imported with cgo_import_dynamic (like libc_open), and pass them along with arguments to syscall.syscall (which is implemented as runtime.syscall_syscall). syscall_syscall informs the scheduler and profiler, and then uses asmcgocall to switch to a system stack and invoke runtime.syscall. The latter is an assembly trampoline that unpacks the Go ABI arguments passed to syscall.syscall, finally calls the remote function, and puts the return value on the Go stack. (This last bit is the part that cgo compiles from a C wrapper.) We can do something similar to link and invoke Security.framework! The one difference is that runtime.syscall and friends check errors based on the errno convention, which Security doesn't follow, so I added runtime.syscallNoErr which just skips interpreting the return value. We only need a variant with six arguments because the calling convention is register-based, and extra arguments simply zero out some registers. That's plumbed through as crypto/x509/internal/macOS.syscall. The rest of that package is a set of wrappers for Security.framework and Core Foundation functions, like syscall is for libSystem. In theory, as long as macOS respects ABI backwards compatibility (a.k.a. as long as binaries built for a previous OS version keep running) this should be stable, as the final result is not different from what a C compiler would make. (One exception might be dictionary key strings, which we make our own copy of instead of using the dynamic symbol. If they change the value of those strings things might break. But why would they.) Finally, I rewrote the crypto/x509 cgo logic in Go using those wrappers. It works! I tried to make it match 1:1 the old logic, so that root_darwin_amd64.go can be reviewed by comparing it to root_cgo_darwin_amd64.go. The only difference is that we do proper error handling now, and assume that if there is no error the return values are there, while before we'd just check for nil pointers and move on. I kept the cgo logic to help with review and testing, but we should delete it once we are confident the new code works. The nocgo logic is gone and we shall never speak of it again. Fixes #32604 Fixes #19561 Fixes #38365 Awakens Cthulhu Change-Id: Id850962bad667f71e3af594bdfebbbb1edfbcbb4 Reviewed-on: https://go-review.googlesource.com/c/go/+/227037 Reviewed-by: Katie Hockman <katie@golang.org>
2020-04-08all: remove scattered remnants of darwin/386Austin Clements
This removes all conditions and conditional code (that I could find) that depended on darwin/386. Fixes #37610. Change-Id: I630d9ea13613fb7c0bcdb981e8367facff250ba0 Reviewed-on: https://go-review.googlesource.com/c/go/+/227582 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-11-25runtime: add go:nosplit to cgo_mmap.go:mmap() and sys_darwin.go:mmap()Dan Scales
cgo_mmap.go:mmap() is called by mem_linux.go:sysAlloc(), a low-level memory allocation function. mmap() should be nosplit, since it is called in a lot of low-level parts of the runtime and callers often assume it won't acquire any locks. As an example there is a potential deadlock involving two threads if mmap is not nosplit: trace.bufLock acquired, then stackpool[order].item.mu, then mheap_.lock - can happen for traceEvents that are not invoked on the system stack and cause a traceFlush, which causes a sysAlloc, which calls mmap(), which may cause a stack split. mheap_.lock mheap_.lock acquired, then trace.bufLock - can happen when doing a trace in reclaimChunk (which holds the mheap_ lock) Also, sysAlloc() has a comment that it is nosplit because it may be invoked without a valid G, in which case its callee mmap() should also be nosplit. Similarly, sys_darwin.go:mmap() is called by mem_darwin.go:sysAlloc(), and should be nosplit for the same reasons. Extra gomote testing: linux/arm64, darwin/amd64 Change-Id: Ia4d10cec5cf1e186a0fe5aab2858c6e0e5b80fdc Reviewed-on: https://go-review.googlesource.com/c/go/+/207844 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-10-26runtime: M-targeted signals for libc-based OSesAustin Clements
For #10958, #24543. Change-Id: I82bee63b49e15bd5a53228eb85179814c80437ef Reviewed-on: https://go-review.googlesource.com/c/go/+/201403 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-10-01runtime: fix darwin syscall performance regressionShenghou Ma
While understanding why syscall.Read is 2x slower on darwin/amd64, I found out that, contrary to popular belief, the slowdown is not due to the migration to use libSystem.dylib instead of direct SYSCALLs, i.e., CL 141639 (and #17490), but due to a subtle change introduced in CL 141639. Previously, syscall.Read used syscall.Syscall(SYS_READ), whose preamble called runtime.entersyscall, but after CL 141639, syscall.Read changes to call runtime.syscall_syscall instead, which in turn calls runtime.entersyscallblock instead of runtime.entersyscall. And the entire 2x slow down can be attributed to this change. I think this is unnecessary as even though syscalls like Read might block, it does not always block, so there is no need to handoff P proactively for each Read. Additionally, we have been fine with not handing off P for each Read prior to Go 1.12, so we probably don't need to change it. This changes restores the pre-Go 1.12 behavior, where syscall preamble uses runtime.entersyscall, and we rely on sysmon to take P back from g blocked in syscalls. Change-Id: If76e97b5a7040cf1c10380a567c4f5baec3121ba Reviewed-on: https://go-review.googlesource.com/c/go/+/197938 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-09-04runtime: wrap nanotime, walltime, and writeAustin Clements
In preparation for general faketime support, this renames the existing nanotime, walltime, and write functions to nanotime1, walltime1, and write1 and wraps them with trivial Go functions. This will let us inject different implementations on all platforms when faketime is enabled. Updates #30439. Change-Id: Ice5ccc513a32a6d89ea051638676d3ee05b00418 Reviewed-on: https://go-review.googlesource.com/c/go/+/192738 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-06-30runtime: use a pipe to wake up signal_recv on DarwinIan Lance Taylor
The implementation of semaphores, and therefore notes, used on Darwin is not async-signal-safe. The runtime has one case where a note needs to be woken up from a signal handler: the call to notewakeup in sigsend. That notewakeup call is only called on a single note, and it doesn't need the full functionality of notes: nothing ever does a timed wait on it. So change that one note to use a different implementation on Darwin, based on a pipe. This lets the wakeup code use the write call, which is async-signal-safe. Fixes #31264 Change-Id: If705072d7a961dd908ea9d639c8d12b222c64806 Reviewed-on: https://go-review.googlesource.com/c/go/+/184169 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2019-06-21Revert "runtime: use dispatch semaphores on Darwin"Ian Lance Taylor
This reverts https://golang.org/cl/182258. The new code caused unpredictable crashes that are not understood. The old code was occasionally flaky but still better than this approach. Fixes #32655 Updates #31264 Change-Id: I2e9d27d6052e84bf75106d8b844549ba4f571695 Reviewed-on: https://go-review.googlesource.com/c/go/+/182880 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2019-06-15runtime: use dispatch semaphores on DarwinIan Lance Taylor
Changes Darwin semaphore support from using pthread mutexes and condition variables to using dispatch semaphores. Signaling a dispatch semaphore is async-signal-safe. Fixes #31264 Change-Id: If0ce47623501db13e3804b14ace5f4d8eaef461e Reviewed-on: https://go-review.googlesource.com/c/go/+/182258 Reviewed-by: Elias Naur <mail@eliasnaur.com> Reviewed-by: Keith Randall <khr@golang.org>
2019-06-06runtime: mark all Go symbols called from assembly in other packagesAustin Clements
This marks all Go symbols called from assembly in other packages with "go:linkname" directives to ensure they get ABI wrappers. Now that we have this go:linkname convention, this also removes the abi0Syms definition in the runtime, which was used to give morestackc an ABI0 wrapper. Instead, we now just mark morestackc with a go:linkname directive. This was tested with buildall.bash in the default configuration, with -race, and with -gcflags=all=-d=ssa/intrinsics/off. Since I couldn't test cgo on non-Linux configurations, I manually grepped for runtime symbols in runtime/cgo. Updates #31230. Change-Id: I6c8aa56be2ca6802dfa2bf159e49c411b9071bf1 Reviewed-on: https://go-review.googlesource.com/c/go/+/179862 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2019-06-06runtime: use default system stack size, not 64 kB, on non-cgo macOSRuss Cox
At least one libc call we make (res_search, which calls _mdns_query and then mdns_item_call) pushes a 64 kB stack frame onto the stack. Then it faults on the guard page. Use the default system stack size, under the assumption that the C code being called is compatible with that stack size. For #31705. Change-Id: I1b0bfc2e54043c49f0709255988ef920ce30ee82 Reviewed-on: https://go-review.googlesource.com/c/go/+/180779 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-04-03syscall: avoid _getdirentries64 on darwinKeith Randall
Getdirentries is implemented with the __getdirentries64 function in libSystem.dylib. That function works, but it's on Apple's can't-be-used-in-an-app-store-application list. Implement Getdirentries using the underlying fdopendir/readdir_r/closedir. The simulation isn't faithful, and could be slow, but it should handle common cases. Don't use Getdirentries in the stdlib, use fdopendir/readdir_r/closedir instead (via (*os.File).readdirnames). Fixes #30933 Update #28984 RELNOTE=yes Change-Id: Ia6b5d003e5bfe43ba54b1e1d9cfa792cc6511717 Reviewed-on: https://go-review.googlesource.com/c/go/+/168479 Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-11-07syscall: implement syscalls on Darwin using libSystemKeith Randall
There are still some references to the bare Syscall functions in the stdlib. I will root those out in a following CL. (This CL is big enough as it is.) Most are in vendor directories: cmd/vendor/golang.org/x/sys/unix/ vendor/golang_org/x/net/route/syscall.go syscall/bpf_bsd.go syscall/exec_unix.go syscall/flock.go Update #17490 Change-Id: I69ab707811530c26b652b291cadee92f5bf5c1a4 Reviewed-on: https://go-review.googlesource.com/c/141639 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Elias Naur <elias.naur@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-09-15runtime: fix TODO comment filepathKoichi Shiraishi
The cmd/compile/internal/ld/go.go file not exist, actually cmd/link/internal/ld/go.go. Also, write line number is not good because it changes every commit of the file. Change-Id: Id2b9f2c9904390adb011dab357716ee8e2fe84fc Reviewed-on: https://go-review.googlesource.com/135516 Reviewed-by: Ian Lance Taylor <iant@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 23:32:15 +0000