aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/asm_amd64.s
AgeCommit message (Collapse)Author
2023-01-25runtime: mark amd64 runtime·rt0_go as NOFRAMEqmuntal
This CL adds the NOFRAME flag to runtime·rt0_go, which should had been added in CL 459395 but didn't and broke fix windows-amd64-2008. Change-Id: I4583f2034bf114e1f7aaddef9ba505f53536c3eb Reviewed-on: https://go-review.googlesource.com/c/go/+/463120 Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Quim Muntal <quimmuntal@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-01-24runtime: use explicit NOFRAME on windows/amd64qmuntal
This CL marks non-leaf nosplit assembly functions as NOFRAME to avoid relying on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions without stack were also marked as NOFRAME. Updates #57302 Updates #40044 Change-Id: Ia4d26f8420dcf2b54528969ffbf40a73f1315d61 Reviewed-on: https://go-review.googlesource.com/c/go/+/459395 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-01-24runtime: switch AMD64's publicationBarrier to ABIInternalJakub Ciolek
Shrinks a few runtime functions: runtime runtime.mallocgc 2127 -> 2117 (-0.47%) runtime.(*mheap).initSpan 652 -> 639 (-1.99%) runtime.(*mspan).userArenaNextFree 825 -> 808 (-2.06%) file before after Δ % runtime.s 512473 512414 -59 -0.012% total 20843331 20843272 -59 -0.000% Change-Id: Ifaca7abb6db3467b73945fac71496dd7527e6863 Reviewed-on: https://go-review.googlesource.com/c/go/+/462296 Auto-Submit: Keith Randall <khr@golang.org> Run-TryBot: Jakub Ciolek <jakub@ciolek.dev> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2023-01-20runtime: remove 104 byte stack guardliu-xuewen
The number 104 appears to date back to the first implementation of split stacks in https://go.googlesource.com/go/+/b987f7a757f53f460973622a36eebb696f9b5060. That change introduces a 104 byte stack guard. it doesn't makes any sense today. Change-Id: I73069f6d1a827653af63e616f0119fbac809882e GitHub-Last-Rev: bcf900059047548c1709c6d4cf4649a96ad85e57 GitHub-Pull-Request: golang/go#56594 Reviewed-on: https://go-review.googlesource.com/c/go/+/448036 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2022-11-14runtime,cmd/internal/obj/x86: use TEB TLS slots on windows/amd64qmuntal
This CL redesign how we get the TLS pointer on windows/amd64. We were previously reading it from the [TEB] arbitrary data slot, located at 0x28(GS), which can only hold 1 TLS pointer. With this CL, we will read the TLS pointer from the TEB TLS slot array, located at 0x1480(GS). The TLS slot array can hold multiple TLS pointers, up to 64, so multiple Go runtimes running on the same thread can coexists with different TLS. Each new TLS slot has to be allocated via [TlsAlloc], which returns the slot index. This index can then be used to get the slot offset from GS with the following formula: 0x1480 + index*8 The slot index is fixed per Go runtime, so we can store it in runtime.tls_g and use it latter on to read/update the TLS pointer. Loading the TLS pointer requires the following asm instructions: MOVQ runtime.tls_g, AX MOVQ AX(GS), AX Notice that this approach is also implemented on windows/arm64. [TEB]: https://en.wikipedia.org/wiki/Win32_Thread_Information_Block [TlsAlloc]: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsalloc Updates #22192 Change-Id: Idea7119fd76a3cd083979a4d57ed64b552fa101b Reviewed-on: https://go-review.googlesource.com/c/go/+/431775 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
2022-05-18all: fix spellingJohn Bampton
Change-Id: I63eb42f3ce5ca452279120a5b33518f4ce16be45 GitHub-Last-Rev: a88f2f72bef402344582ae997a4907457002b5df GitHub-Pull-Request: golang/go#52951 Reviewed-on: https://go-review.googlesource.com/c/go/+/406843 Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2022-04-01runtime: check GOAMD64 v4 compatibility on Darwinvpachkov
Darwin requires a different approach to check AVX512 support. Update #45453 Change-Id: Ia3dfecc04b47aab16f472000e92e46d4fc6d596d Reviewed-on: https://go-review.googlesource.com/c/go/+/365395 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Trust: Heschi Kreinick <heschi@google.com>
2021-11-16runtime: check GOAMD64 compatibility after setting up TLSKeith Randall
We need TLS set up to be able to print an error without crashing. Fixes #49586 Update #45453 Change-Id: I97f0efcd716a8dca614e82ab73f2d855b7277599 Reviewed-on: https://go-review.googlesource.com/c/go/+/364174 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Martin Möhrmann <martin@golang.org> Trust: Martin Möhrmann <martin@golang.org> Trust: Keith Randall <khr@golang.org>
2021-11-02runtime: check amd64 microarchitecture level at startupvpachkov
Make Go runtime throw if it's been compiled to assume instruction set extensions that aren't available on the CPU. Updates #48506 Change-Id: Ic4d6696e1cd6b28d389a86fe64e8175ea3ca135a GitHub-Last-Rev: ba338377f549344b416fbd519576e95ce5d523be GitHub-Pull-Request: golang/go#48514 Reviewed-on: https://go-review.googlesource.com/c/go/+/351191 Run-TryBot: Martin Möhrmann <martin@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Martin Möhrmann <martin@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Martin Möhrmann <martin@golang.org>
2021-08-23runtime: use RDTSCP for instruction stream serialized read of TSCMartin Möhrmann
To measure all instructions having been completed before reading the time stamp counter with RDTSC an instruction sequence that has instruction stream serializing properties which guarantee waiting until all previous instructions have been executed is needed. This does not necessary mean to wait for all stores to be globally visible. This CL aims to remove vendor specific logic for determining the instruction sequence with CPU feature flag checks that are CPU vendor independent. For intel LFENCE has the wanted properties at least since it was introduced together with SSE2 support. On AMD instruction stream serializing LFENCE is supported by setting an MSR C001_1029[1]=1 on AMD family 10h/12h/14h/15h/16h/17h processors. AMD family 0Fh/11h processors support LFENCE as serializing always. AMD plans support for this MSR and access to this bit for all future processors. Source: https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf Reading the MSR to determine LFENCE properties is not always possible or reliable (hypervisors). The Linux kernel is relying on serializing LFENCE on AMD CPUs since a commit in July 2019: https://lkml.org/lkml/2019/7/22/295 and the MSR C001_1029 to enable serialization has been set by default with the Spectre v1 mitigations. Using an MFENCE on AMD is waiting on previous instructions having been executed but in addition also flushes store buffers. To align the serialization properties without runtime detection of CPU manufacturers we can use the newer RDTSCP instruction which waits until all previous instructions have been executed. RDTSCP is available on Intel since around 2008 and on AMD CPUs since around 2006. Support for RDTSCP can be checked independently of manufacturer by checking CPUID bits. Using RDTSCP is the default in Linux to read TSC in program order when the instruction is available. https://github.com/torvalds/linux/blob/e22ce8eb631bdc47a4a4ea7ecf4e4ba499db4f93/arch/x86/include/asm/msr.h#L231 Change-Id: Ifa841843b9abb2816f8f0754a163ebf01385306d Reviewed-on: https://go-review.googlesource.com/c/go/+/344429 Reviewed-by: Keith Randall <khr@golang.org> Trust: Martin Möhrmann <martin@golang.org> Run-TryBot: Martin Möhrmann <martin@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
2021-08-16runtime: make asmcgocall g0/gsignal checks consistentJoel Sing
In asmcgocall() we need to switch to the g0 stack if we're not already on the g0 stack or the gsignal stack. The prefered way of doing this is to check gsignal first, then g0, since if we are going to switch to g0 we will need g0 handy (thus avoiding a second load). Rewrite/reorder 386 and amd64 to check gsignal first - this shaves a few assembly instructions off and makes the order consistent with arm, arm64, mips64 and ppc64. Add missing gsignal checks to mips, riscv64 and s390x. Change-Id: I1b027bf393c25e0c33e1d8eb80de67e4a0a3f561 Reviewed-on: https://go-review.googlesource.com/c/go/+/335869 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 Mui <cherryyz@google.com>
2021-08-11[dev.typeparams] runtime, internal/bytealg: remove regabi fallback code on AMD64Cherry Mui
As we commit to always enabling register ABI on AMD64, remove the fallback code. Change-Id: I30556858ba4bac367495fa94f6a8682ecd771196 Reviewed-on: https://go-review.googlesource.com/c/go/+/341152 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Austin Clements <austin@google.com>
2021-08-03[dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loopAustin Clements
Currently, deferreturn runs deferred functions by backing up its return PC to the deferreturn call, and then effectively tail-calling the deferred function (via jmpdefer). The effect of this is that the deferred function appears to be called directly from the deferee, and when it returns, the deferee calls deferreturn again so it can run the next deferred function if necessary. This unusual flow control leads to a large number of special cases and complications all over the tool chain. This used to be necessary because deferreturn copied the deferred function's argument frame directly into its caller's frame and then had to invoke that call as if it had been called from its caller's frame so it could access it arguments. But now that we've simplified defer processing so the runtime only deals with argument-less closures, this approach is no longer necessary. This CL simplifies all of this by making deferreturn simply call deferred functions in a loop. This eliminates the need for jmpdefer, so we can delete a bunch of per-architecture assembly code. This eliminates several special cases on Wasm, since it couldn't support these calling shenanigans directly and thus had to simulate the loop a different way. Now Wasm can largely work the way the other platforms do. This eliminates the per-architecture Ginsnopdefer operation. On PPC64, this was necessary to reload the TOC pointer after the tail call (since TOC pointers in general make tail calls impossible). The tail call is gone, and in the case where we do force a jump to the deferreturn call when recovering from an open-coded defer, we go through gogo (via runtime.recovery), which handles the TOC. On other platforms, we needed a NOP so traceback didn't get confused by seeing the return to the CALL instruction, rather than the usual return to the instruction following the CALL instruction. Now we don't inject a return to the CALL instruction at all, so this NOP is also unnecessary. The one potential effect of this is that deferreturn could now appear in stack traces from deferred functions. However, this could already happen from open-coded defers, so we've long since marked deferreturn as a "wrapper" so it gets elided not only from printed stack traces, but from runtime.Callers*. This is a retry of CL 337652 because we had to back out its parent. There are no changes in this version. Change-Id: I3f54b7fec1d7ccac71cc6cf6835c6a46b7e5fb6c Reviewed-on: https://go-review.googlesource.com/c/go/+/339397 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2021-07-30[dev.typeparams] Revert "[dev.typeparams] runtime,cmd/compile,cmd/link: ↵Austin Clements
replace jmpdefer with a loop" This reverts CL 227652. I'm reverting CL 337651 and this builds on top of it. Change-Id: I03ce363be44c2a3defff2e43e7b1aad83386820d Reviewed-on: https://go-review.googlesource.com/c/go/+/338709 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2021-07-30[dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loopAustin Clements
Currently, deferreturn runs deferred functions by backing up its return PC to the deferreturn call, and then effectively tail-calling the deferred function (via jmpdefer). The effect of this is that the deferred function appears to be called directly from the deferee, and when it returns, the deferee calls deferreturn again so it can run the next deferred function if necessary. This unusual flow control leads to a large number of special cases and complications all over the tool chain. This used to be necessary because deferreturn copied the deferred function's argument frame directly into its caller's frame and then had to invoke that call as if it had been called from its caller's frame so it could access it arguments. But now that we've simplified defer processing so the runtime only deals with argument-less closures, this approach is no longer necessary. This CL simplifies all of this by making deferreturn simply call deferred functions in a loop. This eliminates the need for jmpdefer, so we can delete a bunch of per-architecture assembly code. This eliminates several special cases on Wasm, since it couldn't support these calling shenanigans directly and thus had to simulate the loop a different way. Now Wasm can largely work the way the other platforms do. This eliminates the per-architecture Ginsnopdefer operation. On PPC64, this was necessary to reload the TOC pointer after the tail call (since TOC pointers in general make tail calls impossible). The tail call is gone, and in the case where we do force a jump to the deferreturn call when recovering from an open-coded defer, we go through gogo (via runtime.recovery), which handles the TOC. On other platforms, we needed a NOP so traceback didn't get confused by seeing the return to the CALL instruction, rather than the usual return to the instruction following the CALL instruction. Now we don't inject a return to the CALL instruction at all, so this NOP is also unnecessary. The one potential effect of this is that deferreturn could now appear in stack traces from deferred functions. However, this could already happen from open-coded defers, so we've long since marked deferreturn as a "wrapper" so it gets elided not only from printed stack traces, but from runtime.Callers*. Change-Id: Ie9f700cd3fb774f498c9edce363772a868407bf7 Reviewed-on: https://go-review.googlesource.com/c/go/+/337652 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2021-07-30[dev.typeparams] runtime: use func() for deferred functionsAustin Clements
Prior to regabi, a deferred function could have any signature, so the runtime always manipulated them as funcvals. Now, a deferred function is always func(). Hence, this CL makes the runtime's manipulation of deferred functions more type-safe by using func() directly instead of *funcval. Change-Id: Ib55f38ed49107f74149725c65044e4690761971d Reviewed-on: https://go-review.googlesource.com/c/go/+/337650 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2021-06-11[dev.typeparams] all: always enable regabig on AMD64Cherry Mui
Always enable regabig on AMD64, which enables the G register and the X15 zero register. Remove the fallback path. Also remove the regabig GOEXPERIMENT. On AMD64 it is always enabled (this CL). Other architectures already have a G register, except for 386, where there are too few registers and it is unlikely that we will reserve one. (If we really do, we can just add a new experiment). Change-Id: I229cac0060f48fe58c9fdaabd38d6fa16b8a0855 Reviewed-on: https://go-review.googlesource.com/c/go/+/327272 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-06-08[dev.typeparams] cmd/compile, runtime: remove the siz argument of ↵Cherry Mui
newproc/deferproc newproc/deferproc takes a siz argument for the go'd/deferred function's argument size. Now it is always zero. Remove the argument. Change-Id: If1bb8d427e34015ccec0ba10dbccaae96757fa8c Reviewed-on: https://go-review.googlesource.com/c/go/+/325917 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-05-21[dev.typeparams] runtime: use internal/abi.FuncPCABI0 to take address of ↵Cherry Mui
assembly functions There are a few assembly functions in the runtime that are marked as ABIInternal, solely because funcPC can get the right address. The functions themselves do not actually follow ABIInternal (or irrelevant). Now we have internal/abi.FuncPCABI0, use that, and un-mark the functions. Also un-mark assembly functions that are only called in assembly. For them, it only matters if the caller and callee are consistent. Change-Id: I240e126ac13cb362f61ff8482057ee9f53c24097 Reviewed-on: https://go-review.googlesource.com/c/go/+/321950 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-05-20[dev.typeparams] cmd/compile, runtime: do not zero X15 on Plan 9Cherry Mui
On Plan 9, we cannot use SSE registers in note handlers, so we don't use X15 for zeroing (MOVOstorezero and DUFFZERO). Do not zero X15 on Plan 9. Change-Id: I2b083b01b27965611cb83d19afd66b383dc77846 Reviewed-on: https://go-review.googlesource.com/c/go/+/321329 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2021-04-23cmd/compile, internal/abi: add FuncPCABIxxx intrinsicsCherry Zhang
When ABI wrappers are used, there are cases where in Go code we need the PC of the defined function instead of the ABI wrapper. Currently we work around this by define such functions as ABIInternal, even if they do not actually follow the internal ABI. This CL introduces internal/abi.FuncPCABIxxx functions as compiler intrinsics, which return the underlying defined function's entry PC if the argument is a direct reference of a function of the expected ABI, and reject it if it is of a different ABI. As a proof of concept, change runtime.goexit back to ABI0 and use internal/abi.FuncPCABI0 to retrieve its PC. Updates #44065. Change-Id: I02286f0f9d99e6a3090f9e8169dbafc6804a2da6 Reviewed-on: https://go-review.googlesource.com/c/go/+/304232 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2021-04-22runtime: call cgocallbackg indirectlyCherry Zhang
cgocallback calls cgocallbackg after switching the stack. Call it indirectly to bypass the linker's nosplit check. Apparently (at least on Windows) cgocallbackg can use quite a bit stack space in a nosplit chain. We have been running over the nosplit limit, or very close to the limit. Since it switches stack in cgocallback, it is not meaningful to count frames above cgocallback and below cgocallbackg together. Bypass the check. For #45658. Change-Id: Ie22017e3f82d2c1fcc37336696f2d02757856399 Reviewed-on: https://go-review.googlesource.com/c/go/+/312669 Trust: Cherry Zhang <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-04-21cmd/compile: allow conversion from slice to array ptrJosh Bleecher Snyder
Panic if the slice is too short. Updates #395 Change-Id: I90f4bff2da5d8f3148ba06d2482084f32b25c29a Reviewed-on: https://go-review.googlesource.com/c/go/+/301650 Trust: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-04-19runtime: open up space for callee's arg spill slot in mcall (regabi version)Cherry Zhang
mcall calls fn with an argument. Currently, in the regabi version of mcall it does not reserve space for that argument's spill slot. If the callee spills its argument, it may clobber things on the g0 stack at 0(SP) (e.g. the old SP saved in cgocallback). Reserve the space. Change-Id: I85a314273cd996c7fac8fd0b03cd9033faae9c5a Reviewed-on: https://go-review.googlesource.com/c/go/+/311489 Trust: Cherry Zhang <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-04-15runtime: unify C->Go ABI transitionsAustin Clements
The previous CL introduced macros for transitions from the Windows ABI to the Go ABI. This CL does the same for SysV and uses them in almost all places where we transition from the C ABI to the Go ABI. Compared to Windows, this transition is much simpler and I didn't find any places that were getting it wrong. But this does let us unify a lot of code nicely and introduces some degree of abstraction around these ABI transitions. Change-Id: Ib6bdecafce587ce18fca4c8300fcf401284a2bcd Reviewed-on: https://go-review.googlesource.com/c/go/+/309930 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-04-15runtime: minor refactoring of _rt0_amd64_libAustin Clements
This function bounces between the C and Go ABIs a few times. This CL narrows the scope of the Go -> C transition to just around the branch that calls C. This lets us take advantage of C callee-save registers to simplify the code a little. Change-Id: I1ffa0b9e50325425c5ec66596978aeb6450a6b57 Reviewed-on: https://go-review.googlesource.com/c/go/+/309929 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-04-14runtime: update debug call protocol for register ABIMichael Anthony Knyszek
The debug call tests currently assume that the target Go function is ABI0; this is clearly no longer true when we switch to the new ABI, so make the tests set up argument register state in the debug call handler and copy back results returned in registers. A small snag in calling a Go function that follows the new ABI is that the debug call protocol depends on the AX register being set to a specific value as it bounces in and out of the handler, but this register is part of the new register ABI, so results end up being clobbered. Use R12 instead. Next, the new desugaring behavior for "go" statements means that newosproc1 must always call a function with no frame; if it takes any arguments, it closes over them and they're passed in the context register. Currently when debugCallWrap creates a new goroutine, it uses newosproc1 directly and passes a non-zero-sized frame, so that needs to be updated. To fix this, briefly use the g's param field which is otherwise only used for channels to pass an explicitly allocated object containing the "closed over" variables. While we could manually do the desugaring ourselves (we cannot do so automatically because the Go compiler prevents heap-allocated closures in the runtime), that bakes in more ABI details in a place that really doesn't need to care about them. Finally, there's an old bug here where the context register was set up in CX, so technically closure calls never worked. Oops. It was otherwise harmless for other types of calls before, but now CX is an argument register, so now that interferes with regular calls, too. For #40724. Change-Id: I652c25ed56a25741bb04c24cfb603063c099edde Reviewed-on: https://go-review.googlesource.com/c/go/+/309169 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-04-12runtime: port performance-critical functions to regabiAustin Clements
This CL ports a few performance-critical runtime assembly functions to use register arguments directly. While using the faster ABI is nice, the real win here is that we avoid ABI wrappers: since these are "builtin" functions in the compiler, it can generate calls to them without knowing that their native implementation is ABI0. Hence, it generates ABIInternal calls that go through ABI wrappers. By porting them to use ABIInternal natively, we avoid the overhead of the ABI wrapper. This significantly improves performance on several benchmarks, comparing regabiwrappers before and after this change: name old time/op new time/op delta BiogoIgor 15.7s ± 2% 15.7s ± 2% ~ (p=0.617 n=25+25) BiogoKrishna 18.5s ± 5% 17.7s ± 2% -4.61% (p=0.000 n=25+25) BleveIndexBatch100 5.91s ± 3% 5.82s ± 3% -1.60% (p=0.000 n=25+25) BleveQuery 6.76s ± 0% 6.60s ± 1% -2.31% (p=0.000 n=22+25) CompileTemplate 248ms ± 5% 245ms ± 1% ~ (p=0.643 n=25+20) CompileUnicode 94.4ms ± 3% 93.9ms ± 2% ~ (p=0.152 n=24+23) CompileGoTypes 1.60s ± 2% 1.59s ± 2% ~ (p=0.059 n=24+24) CompileCompiler 104ms ± 3% 103ms ± 1% ~ (p=0.056 n=25+22) CompileSSA 10.9s ± 1% 10.9s ± 1% ~ (p=0.052 n=25+25) CompileFlate 156ms ± 8% 152ms ± 1% -2.49% (p=0.008 n=25+21) CompileGoParser 248ms ± 1% 249ms ± 2% ~ (p=0.058 n=21+20) CompileReflect 595ms ± 3% 601ms ± 4% ~ (p=0.182 n=25+25) CompileTar 211ms ± 2% 211ms ± 1% ~ (p=0.663 n=23+23) CompileXML 282ms ± 2% 284ms ± 5% ~ (p=0.456 n=21+23) CompileStdCmd 13.6s ± 2% 13.5s ± 2% ~ (p=0.112 n=25+24) FoglemanFauxGLRenderRotateBoat 8.69s ± 2% 8.67s ± 0% ~ (p=0.094 n=22+25) FoglemanPathTraceRenderGopherIter1 20.2s ± 2% 20.7s ± 3% +2.53% (p=0.000 n=24+24) GopherLuaKNucleotide 31.4s ± 1% 31.0s ± 1% -1.28% (p=0.000 n=25+24) MarkdownRenderXHTML 246ms ± 1% 244ms ± 1% -0.79% (p=0.000 n=20+21) Tile38WithinCircle100kmRequest 843µs ± 4% 818µs ± 4% -2.93% (p=0.000 n=25+25) Tile38IntersectsCircle100kmRequest 1.06ms ± 5% 1.05ms ± 3% -1.19% (p=0.021 n=24+25) Tile38KNearestLimit100Request 1.01ms ± 1% 1.01ms ± 2% ~ (p=0.335 n=22+25) [Geo mean] 596ms 592ms -0.71% (https://perf.golang.org/search?q=upload:20210411.5) It also significantly reduces the performance penalty of enabling regabiwrappers, though it doesn't yet fully close the gap on all benchmarks: name old time/op new time/op delta BiogoIgor 15.7s ± 1% 15.7s ± 2% ~ (p=0.366 n=24+25) BiogoKrishna 17.7s ± 2% 17.7s ± 2% ~ (p=0.315 n=23+25) BleveIndexBatch100 5.86s ± 4% 5.82s ± 3% ~ (p=0.137 n=24+25) BleveQuery 6.55s ± 0% 6.60s ± 1% +0.83% (p=0.000 n=24+25) CompileTemplate 244ms ± 1% 245ms ± 1% ~ (p=0.208 n=21+20) CompileUnicode 94.0ms ± 4% 93.9ms ± 2% ~ (p=0.666 n=24+23) CompileGoTypes 1.60s ± 2% 1.59s ± 2% ~ (p=0.154 n=25+24) CompileCompiler 103ms ± 1% 103ms ± 1% ~ (p=0.905 n=24+22) CompileSSA 10.9s ± 2% 10.9s ± 1% ~ (p=0.803 n=25+25) CompileFlate 153ms ± 1% 152ms ± 1% ~ (p=0.182 n=23+21) CompileGoParser 250ms ± 2% 249ms ± 2% ~ (p=0.843 n=24+20) CompileReflect 595ms ± 4% 601ms ± 4% ~ (p=0.141 n=25+25) CompileTar 212ms ± 3% 211ms ± 1% ~ (p=0.499 n=23+23) CompileXML 282ms ± 1% 284ms ± 5% ~ (p=0.129 n=20+23) CompileStdCmd 13.5s ± 2% 13.5s ± 2% ~ (p=0.480 n=24+24) FoglemanFauxGLRenderRotateBoat 8.66s ± 1% 8.67s ± 0% ~ (p=0.325 n=25+25) FoglemanPathTraceRenderGopherIter1 20.6s ± 3% 20.7s ± 3% ~ (p=0.137 n=25+24) GopherLuaKNucleotide 30.5s ± 2% 31.0s ± 1% +1.68% (p=0.000 n=23+24) MarkdownRenderXHTML 243ms ± 1% 244ms ± 1% +0.51% (p=0.000 n=23+21) Tile38WithinCircle100kmRequest 801µs ± 2% 818µs ± 4% +2.11% (p=0.000 n=25+25) Tile38IntersectsCircle100kmRequest 1.01ms ± 2% 1.05ms ± 3% +4.34% (p=0.000 n=24+25) Tile38KNearestLimit100Request 1.00ms ± 1% 1.01ms ± 2% +0.81% (p=0.008 n=21+25) [Geo mean] 589ms 592ms +0.50% (https://perf.golang.org/search?q=upload:20210411.6) Change-Id: I8f77f010b0abc658064df569a27a9c7a7b1c7bf9 Reviewed-on: https://go-review.googlesource.com/c/go/+/308931 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-04-08runtime: use register ABI in panicIndex/Slice functionsCherry Zhang
runtime.panicIndex*/panicSlice* functions move the arguments in the right place then tail calls goPanicIndex*/Slice* using internal ABI. (It uses internal ABI to avoid wrappers, because the callee needs to get the caller's PC, to know whether it panics in the runtime.) This CL makes it to use the register ABI if it is enabled. Change-Id: Id2ebb51b4bfb3e9aa7cb66d0a9aee63fccee5ecd Reviewed-on: https://go-review.googlesource.com/c/go/+/308649 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-04-08runtime: set up read-only dummy TLS space for needm on WindowsMichael Anthony Knyszek
On Windows, TLS is uninitialized for C threads calling into Go code. In this path, before calling into user Go code, we call into needm which runs without an m, but whose purpose is to pick one up. While in Go code, we may occasionally restore the G register from TLS for a number of reasons. Rather than try to flag all these cases, given that needm (and its callees) are already somewhat special, just set up a dummy TLS space for it that's read-only. If it ever actually tries to write to this space (it shouldn't), it will fail loudly. Otherwise, code that restores the G register will simply load a zero value, but that's OK since needm is careful never to require the G at any point, because it doesn't yet have a valid G. Furthermore, by the time needm returns, it will have set up TLS properly for a Windows C thread, so there's no need to do anything extra afterwards. For #40724. Change-Id: I34e8095059817e4ee663505e89cda8785b634b98 Reviewed-on: https://go-review.googlesource.com/c/go/+/307872 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-04-08cmd/asm,runtime: reduce spellings of GOEXPERIMENTsAustin Clements
Currently, the objabi.Experiment fields use Go-standard CamelCase, the GOEXPERIMENT environment variable flags and build tags use all lowercase, and the asm macros use upper-case with underscores. This CL makes asm use the lowercase names for macros so there is one less spelling, e.g., GOEXPERIMENT_regabiargs. This also makes them consistent with the GOOS_* and GOARCH_* macros, which also use lower case. Change-Id: I305cd89af5e8cd1a89cc148746c034bcfd76db3c Reviewed-on: https://go-review.googlesource.com/c/go/+/307816 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-04-06runtime: make reflectcall ABI0 on amd64Michael Anthony Knyszek
reflectcall expects the ABI0 calling convention, but it's marked as ABIInternal. When it gets called this way, naturally it doesn't work very well. For #40724. Change-Id: Ic76237420cd8c72f5df1c1ac7972ad6f989f8402 Reviewed-on: https://go-review.googlesource.com/c/go/+/306931 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-04-02reflect: add register ABI support for makeFuncStub and methodValueCallMichael Anthony Knyszek
This change finishes off functionality register ABI for the reflect package. Specifically, it implements a call on a MakeFunc'd value by performing the reverse process that reflect.Value.Call does, using the same ABI steps. It implements a call on a method value created by reflect by translating between the method value's ABI to the method's ABI. Tests are added for both cases. For #40724. Change-Id: I302820b61fc0a8f94c5525a002bc02776aef41af Reviewed-on: https://go-review.googlesource.com/c/go/+/298670 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-04-01runtime: fix uses of ABIInternal PCs in assemblyAustin Clements
The covers three kinds of uses: 1. Calls of closures from assembly. These are always ABIInternal calls without wrappers. I went through every indirect call in the runtime and I think mcall is the only case of assembly calling a Go closure in a way that's affected by ABIInternal. systemstack also calls a closure, but it takes no arguments. 2. Calls of Go functions that expect raw ABIInternal pointers. I also only found one of these: callbackasm1 -> cgocallback on Windows. These are trickier to find, though. 3. Finally, I found one case on NetBSD where new OS threads were directly calling the Go runtime entry-point from assembly via a PC, rather than going through a wrapper. This meant new threads may not have special registers set up. In this case, a change on all other OSes had already forced new thread entry to go through an ABI wrapper, so I just caught NetBSD up with that change. With this change, I'm able to run a "hello world" with GOEXPERIMENT=regabi,regabiargs. For #40724. Change-Id: I2a6d0e530c4fd4edf13484d923891c6160d683aa Reviewed-on: https://go-review.googlesource.com/c/go/+/305669 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-03-24runtime: bypass ABI wrapper when calling needm on WindowsMichael Anthony Knyszek
On Windows, when calling into needm in cgocallback on a new thread that is unknown to the Go runtime, we currently call through an ABI wrapper. The ABI wrapper tries to restore the G register from TLS. On other platforms, TLS is set up just enough that the wrapper will simply load a nil g from TLS, but on Windows TLS isn't set up at all, so there's nowhere for the wrapper to load from. So, bypass the wrapper in the call to needm. needm takes no arguments and returns no results so there are no special ABI considerations, except that we must clear X15 which is used as a zero register in Go code (a function normally performed by the ABI wrapper). needm is also otherwise already special and carefully crafted to avoid doing anything that would require a valid G or M, at least until it is able to create one. While we're here, this change simplifies setg so that it doesn't set up TLS on Windows and instead provides an OS-specific osSetupTLS to do that. The result of this is that setg(nil) no longer clears the TLS space pointer on Windows. There's exactly one place this is used (dropm) where it doesn't matter anymore, and an empty TLS means that setg's wrapper will crash on the return path. Another result is that the G slot in the TLS will be properly cleared, however, which isn't true today. For #40724. Change-Id: I65c3d924a3b16abe667b06fd91d467d6d5da31d7 Reviewed-on: https://go-review.googlesource.com/c/go/+/303070 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-03-18all: explode GOEXPERIMENT=regabi into 5 sub-experimentsAustin Clements
This separates GOEXPERIMENT=regabi into five sub-experiments: regabiwrappers, regabig, regabireflect, regabidefer, and regabiargs. Setting GOEXPERIMENT=regabi now implies the working subset of these (currently, regabiwrappers, regabig, and regabireflect). This simplifies testing, helps derisk the register ABI project, and will also help with performance comparisons. This replaces the -abiwrap flag to the compiler and linker with the regabiwrappers experiment. As part of this, regabiargs now enables registers for all calls in the compiler. Previously, this was statically disabled in regabiEnabledForAllCompilation, but now that we can control it independently, this isn't necessary. For #40724. Change-Id: I5171e60cda6789031f2ef034cc2e7c5d62459122 Reviewed-on: https://go-review.googlesource.com/c/go/+/302070 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2021-03-05reflect: use global variables for register countMichael Anthony Knyszek
This change switches reflect to use global variables for ABI-related register counts instead of internal/abi constants. The advantage of doing so is that we can make the internal/abi constants non-zero and enable the runtime register argument spiller/unspiller even if they're not used. It's basically turning two things we need to flip when we switch to the register ABI into one. It also paves the way for testing the reflect register ABI path independently, because now we can switch the global variables at will and run the register-assignment algorithm in tests without having the rest of the runtime be broken. Change-Id: Ie23629a37a5c80aeb24909d4bd9eacbd3f0c06d9 Reviewed-on: https://go-review.googlesource.com/c/go/+/293149 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-02-19runtime: fix spurious stack overflow detectionRuss Cox
The regabi builders are unhappy about badctxt calling throw calling systemstack calling gosave_systemstack_switch calling badctxt, all nosplit, repeating. This wouldn't actually happen since after one systemstack we'd end up on the system stack and the next one wouldn't call gosave_systemstack_switch at all. The badctxt call itself is in a very unlikely assertion failure inside gosave_systemstack_switch. Keep the assertion check but call runtime.abort instead on failure, breaking the detected (but not real) cycle. Change-Id: Iaf5c0fc065783b8c1c6d0f62d848f023a0714b96 Reviewed-on: https://go-review.googlesource.com/c/go/+/294069 Trust: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-02-19runtime: use TOPFRAME to identify top-of-frame functionsRuss Cox
No change to actual runtime, but helps reduce the laundry list of functions. mcall, morestack, and asmcgocall are not actually top-of-frame, so those need more attention in follow-up CLs. mstart moved to assembly so that it can be marked TOPFRAME. Since TOPFRAME also tells DWARF consumers not to unwind this way, this change should also improve debuggers a marginal amount. 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: If1e0d46ca973de5e46b62948d076f675f285b5d9 Reviewed-on: https://go-review.googlesource.com/c/go/+/288802 Trust: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-02-19runtime: remove unnecessary writes to gp.sched.gRuss Cox
A g's sched.g is set in newproc1: newg.sched.g = guintptr(unsafe.Pointer(newg)) After that, it never changes. Yet lots of assembly code does "g.sched.g = g" unnecessarily. Remove all those lines to avoid confusion about whether it ever changes. Also, split gogo into two functions, one that does the nil g check and a second that does the actual switch. This way, if the nil g check fails, we get a stack trace showing the call stack that led to the failure. (The SP write would otherwise cause the stack trace to abort.) Also restore the proper nil g check in a handful of assembly functions. (There is little point in checking for nil g *after* installing it as the real g.) Change-Id: I22866b093f901f765de1d074e36eeec10366abfb Reviewed-on: https://go-review.googlesource.com/c/go/+/292109 Trust: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-02-19runtime: unify asmcgocall and systemstack traceback setupRuss Cox
Both asmcgocall and systemstack need to save the calling Go code's context for use by traceback, but they do it differently. Systemstack's appraoch is better, because it doesn't require a special case in traceback. So make them both use that. While we are here, the fake mstart caller in systemstack is no longer needed and can be removed. (traceback knows to stop in systemstack because of the writes to SP.) Also remove the fake mstarts in sys_windows_*.s. And while we are there, fix the control flow guard code in sys_windows_arm.s. The current code is using pointers to a stack frame that technically is gone once we hit the RET instruction. Clearly it's working OK, but better not to depend on data below SP being preserved, even for just a few instructions. Store the value we need in other registers instead. (This code is only used for pushing a sigpanic call, which does not actually return to the site of the fault and therefore doesn't need to preserve any of the registers.) 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: Id1e3ef5e54f7ad786e4b87043f2626eba7c3bbd9 Reviewed-on: https://go-review.googlesource.com/c/go/+/288799 Trust: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
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-02-16[dev.regabi] runtime: stub out spillArgs and unspillArgsMichael Anthony Knyszek
Currently these two functions assume that constants in internal/abi are set correctly, but we actually just made them zero if GOEXPERIMENT_REGABI is set. This means reflectcall is broken. Fix it by stubbing out these routines even if GOEXPERIMENT_REGABI is set. Change-Id: I4c8df6d6af28562c5bb7b85f48c03d37daa9ee0d Reviewed-on: https://go-review.googlesource.com/c/go/+/292650 Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com>
2021-02-16[dev.regabi] reflect: support for register ABI on amd64 for reflect.(Value).CallMichael Anthony Knyszek
This change adds support for the new register ABI on amd64 to reflect.(Value).Call. If internal/abi's register counts are non-zero, reflect will try to set up arguments in registers on the Call path. Note that because the register ABI becomes ABI0 with zero registers available, this should keep working as it did before. This change does not add any tests for the register ABI case because there's no way to do so at the moment. For #40724. Change-Id: I8aa089a5aa5a31b72e56b3d9388dd3f82203985b Reviewed-on: https://go-review.googlesource.com/c/go/+/272568 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2021-02-08[dev.regabi] runtime: use g register in some assembly functions on AMD64Cherry Zhang
Now that we have a g register, just use it. Note: functions that can be called from ABI0 context (e.g. morestack) is unchanged. Functions that switch g is also unchanged, because we need to set the new g in both the register and TLS. TODO: other OSes. Change-Id: I692a82a7caa8417ff620a59676a6275f56747b94 Reviewed-on: https://go-review.googlesource.com/c/go/+/289718 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-02-08[dev.regabi] runtime: initialize special registers before sigpanicCherry Zhang
In case that we are panicking in ABI0 context or external code, special registers are not initialized. Initialized them in injected code before calling sigpanic. TODO: Windows, Plan 9. Change-Id: I0919b80e7cc55463f3dd94f1f63cba305717270a Reviewed-on: https://go-review.googlesource.com/c/go/+/289710 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jeremy Faller <jeremy@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-02-08[dev.regabi] cmd/compile, runtime: reserve R14 as g registers on AMD64Cherry Zhang
This is a proof-of-concept change for using the g register on AMD64. getg is now lowered to R14 in the new ABI. The g register is not yet used in all places where it can be used (e.g. stack bounds check, runtime assembly code). Change-Id: I10123ddf38e31782cf58bafcdff170aee0ff0d1b Reviewed-on: https://go-review.googlesource.com/c/go/+/289196 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: David Chase <drchase@google.com>
2021-02-05[dev.regabi] runtime: delete gosave functionCherry Zhang
The runtime.gosave function is not used anywhere. Delete. Note: there is also a gosave<> function, which is actually used and not deleted. Change-Id: I64149a7afdd217de26d1e6396233f2becfad7153 Reviewed-on: https://go-review.googlesource.com/c/go/+/289719 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-02-05[dev.regabi] runtime: don't mark rt0_go ABIInternalCherry Zhang
rt0_go is not actually ABIInternal, and it actually has callers (e.g. _rt0_amd64). Change-Id: Id730176e620ad9f443e6bfca6ded81a1367531ba Reviewed-on: https://go-review.googlesource.com/c/go/+/289193 Trust: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2021-01-22[dev.regabi] all: merge master (dab3e5a) into dev.regabiMatthew Dempsky
This merge had two conflicts to resolve: 1. The embed code on master had somewhat substantially diverged, so this CL tediously backported the changes to dev.regabi. In particular, I went through all of the embed changes to gc/{embed,noder,syntax}.go and made sure the analogous code on dev.regabi in noder/noder.go and staticdata/embed.go mirrors it. 2. The init-cycle reporting code on master was extended slightly to track already visited declarations to avoid exponential behavior. The same fix is applied on dev.regabi, just using ir.NameSet instead of map[ir.Node]bool. Conflicts: - src/cmd/compile/internal/gc/embed.go - src/cmd/compile/internal/gc/noder.go - src/cmd/compile/internal/gc/syntax.go - src/cmd/compile/internal/pkginit/initorder.go - src/embed/internal/embedtest/embed_test.go - src/go/types/stdlib_test.go Merge List: + 2021-01-22 dab3e5affe runtime: switch runtime to libc for openbsd/amd64 + 2021-01-22 a1b53d85da cmd/go: add documentation for test and xtest fields output by go list + 2021-01-22 b268b60774 runtime: remove pthread_kill/pthread_self for openbsd + 2021-01-22 ec4051763d runtime: fix typo in mgcscavenge.go + 2021-01-22 7ece3a7b17 net/http: fix flaky TestDisableKeepAliveUpgrade + 2021-01-22 50cba0506f time: clarify Timer.Reset behavior on AfterFunc Timers + 2021-01-22 cf10e69f17 doc/go1.16: mention net/http.Transport.GetProxyConnectHeader + 2021-01-22 ec1b945265 doc/go1.16: mention path/filepath.WalkDir + 2021-01-22 11def3d40b doc/go1.16: mention syscall.AllThreadsSyscall + 2021-01-21 07b0235609 doc/go1.16: add notes about package-specific fs.FS changes + 2021-01-21 e2b4f1fea5 doc/go1.16: minor formatting fix + 2021-01-21 9f43a9e07b doc/go1.16: mention new debug/elf constants + 2021-01-21 3c2f11ba5b cmd/go: overwrite program name with full path + 2021-01-21 953d1feca9 all: introduce and use internal/execabs + 2021-01-21 b186e4d70d cmd/go: add test case for cgo CC setting + 2021-01-21 5a8a2265fb cmd/cgo: report exec errors a bit more clearly + 2021-01-21 46e2e2e9d9 cmd/go: pass resolved CC, GCCGO to cgo + 2021-01-21 3d40895e36 runtime: switch openbsd/arm64 to pthreads + 2021-01-21 d95ca91380 crypto/elliptic: fix P-224 field reduction + 2021-01-20 ecf4ebf100 cmd/internal/moddeps: check content of all modules in GOROOT + 2021-01-20 d2d155d1ae runtime: don't adjust timer pp field in timerWaiting status + 2021-01-20 803d18fc6c cmd/go: set Incomplete field on go list output if no files match embed + 2021-01-20 6e243ce71d cmd/go: have go mod vendor copy embedded files in subdirs + 2021-01-20 be28e5abc5 cmd/go: fix mod_get_fallback test + 2021-01-20 928bda4f4a runtime: convert openbsd/amd64 locking to libc + 2021-01-19 824f2d635c cmd/go: allow go fmt to complete when embedded file is missing + 2021-01-19 0575e35e50 cmd/compile: require 'go 1.16' go.mod line for //go:embed + 2021-01-19 ccb2e90688 cmd/link: exit before Asmb2 if error + 2021-01-19 ca5774a5a5 embed: treat uninitialized FS as empty + 2021-01-19 d047c91a6c cmd/link,runtime: switch openbsd/amd64 to pthreads + 2021-01-19 61debffd97 runtime: factor out usesLibcall + 2021-01-19 9fed39d281 runtime: factor out mStackIsSystemAllocated + 2021-01-18 dbab079835 runtime: free Windows event handles after last lock is dropped + 2021-01-18 5a8fbb0d2d os: do not close syscall.Stdin in TestReadStdin + 2021-01-15 682a1d2176 runtime: detect errors in DuplicateHandle + 2021-01-15 9f83418b83 cmd/link: remove GOROOT write in TestBuildForTvOS + 2021-01-15 ec9470162f cmd/compile: allow embed into any string or byte slice type + 2021-01-15 54198b04db cmd/compile: disallow embed of var inside func + 2021-01-15 b386c735e7 cmd/go: fix go generate docs + 2021-01-15 bb5075a525 syscall: remove RtlGenRandom and move it into internal/syscall + 2021-01-15 1deae0b597 os: invoke processKiller synchronously in testKillProcess + 2021-01-15 ff196c3e84 crypto/x509: update iOS bundled roots to version 55188.40.9 + 2021-01-14 e125ccd10e cmd/go: in 'go mod edit', validate versions given to -retract and -exclude + 2021-01-14 eb330020dc cmd/dist, cmd/go: pass -arch for C compilation on Darwin + 2021-01-14 84e8a06f62 cmd/cgo: remove unnecessary space in cgo export header + 2021-01-14 0c86b999c3 cmd/test2json: document passing -test.paniconexit0 + 2021-01-14 9135795891 cmd/go/internal/load: report positions for embed errors + 2021-01-14 d9b79e53bb cmd/compile: fix wrong complement for arm64 floating-point comparisons + 2021-01-14 c73232d08f cmd/go/internal/load: refactor setErrorPos to PackageError.setPos + 2021-01-14 6aa28d3e06 go/build: report positions for go:embed directives + 2021-01-13 7eb31d999c cmd/go: add hints to more missing sum error messages + 2021-01-12 ba76567bc2 cmd/go/internal/modload: delete unused *mvsReqs.next method + 2021-01-12 665def2c11 encoding/asn1: document unmarshaling behavior for IMPLICIT string fields + 2021-01-11 81ea89adf3 cmd/go: fix non-script staleness checks interacting badly with GOFLAGS + 2021-01-11 759309029f doc: update editors.html for Go 1.16 + 2021-01-11 c3b4c7093a cmd/internal/objfile: don't require runtime.symtab symbol for XCOFF + 2021-01-08 59bfc18e34 cmd/go: add hint to read 'go help vcs' to GOVCS errors + 2021-01-08 cd6f3a54e4 cmd/go: revise 'go help' documentation for modules + 2021-01-08 6192b98751 cmd/go: make hints in error messages more consistent + 2021-01-08 25886cf4bd cmd/go: preserve sums for indirect deps fetched by 'go mod download' + 2021-01-08 6250833911 runtime/metrics: mark histogram metrics as cumulative + 2021-01-08 8f6a9acbb3 runtime/metrics: remove unused StopTheWorld Description field + 2021-01-08 6598c65646 cmd/compile: fix exponential-time init-cycle reporting + 2021-01-08 fefad1dc85 test: fix timeout code for invoking compiler + 2021-01-08 6728118e0a cmd/go: pass signals forward during "go tool" + 2021-01-08 e65c543f3c go/build/constraint: add parser for build tag constraint expressions + 2021-01-08 0c5afc4fb7 testing/fstest,os: clarify racy behavior of TestFS + 2021-01-08 32afcc9436 runtime/metrics: change unit on *-by-size metrics to match bucket unit + 2021-01-08 c6513bca5a io/fs: minor corrections to Glob doc + 2021-01-08 304f769ffc cmd/compile: don't short-circuit copies whose source is volatile + 2021-01-08 ae97717133 runtime,runtime/metrics: use explicit histogram boundaries + 2021-01-08 a9ccd2d795 go/build: skip string literal while findEmbed + 2021-01-08 d92f8add32 archive/tar: fix typo in comment + 2021-01-08 cab1202183 cmd/link: accept extra blocks in TestFallocate + 2021-01-08 ee4d32249b io/fs: minor corrections to Glob release date + 2021-01-08 54bd1ccce2 cmd: update to latest golang.org/x/tools + 2021-01-07 9ec21a8f34 Revert "reflect: support multiple keys in struct tags" + 2021-01-07 091414b5b7 io/fs: correct WalkDirFunc documentation + 2021-01-07 9b55088d6b doc/go1.16: add release note for disallowing non-ASCII import paths + 2021-01-07 fa90aaca7d cmd/compile: fix late expand_calls leaf type for OpStructSelect/OpArraySelect + 2021-01-07 7cee66d4cb cmd/go: add documentation for Embed fields in go list output + 2021-01-07 e60cffa4ca html/template: attach functions to namespace + 2021-01-07 6da2d3b7d7 cmd/link: fix typo in asm.go + 2021-01-07 df81a15819 runtime: check mips64 VDSO clock_gettime return code + 2021-01-06 4787e906cf crypto/x509: rollback new CertificateRequest fields + 2021-01-06 c9658bee93 cmd/go: make module suggestion more friendly + 2021-01-06 4c668b25c6 runtime/metrics: fix panic message for Float64Histogram + 2021-01-06 d2131704a6 net/http/httputil: fix deadlock in DumpRequestOut + 2021-01-05 3e1e13ce6d cmd/go: set cfg.BuildMod to "readonly" by default with no module root + 2021-01-05 0b0d004983 cmd/go: pass embedcfg to gccgo if supported + 2021-01-05 1b85e7c057 cmd/go: don't scan gccgo standard library packages for imports + 2021-01-05 6b37b15d95 runtime: don't take allglock in tracebackothers + 2021-01-04 9eef49cfa6 math/rand: fix typo in comment + 2021-01-04 b01fb2af9e testing/fstest: fix typo in error message + 2021-01-01 3dd5867605 doc: 2021 is the Year of the Gopher + 2020-12-31 95ce805d14 io/fs: remove darwin/arm64 special condition + 2020-12-30 20d0991b86 lib/time, time/tzdata: update tzdata to 2020f + 2020-12-30 ed301733bb misc/cgo/testcarchive: remove special flags for Darwin/ARM + 2020-12-30 0ae2e032f2 misc/cgo/test: enable TestCrossPackageTests on darwin/arm64 + 2020-12-29 780b4de16b misc/ios: fix wording for command line instructions + 2020-12-29 b4a71c95d2 doc/go1.16: reference misc/ios/README for how to build iOS programs + 2020-12-29 f83e0f6616 misc/ios: add to README how to build ios executables + 2020-12-28 4fd9455882 io/fs: fix typo in comment Change-Id: I2f257bbc5fbb05f15c2d959f8cfe0ce13b083538