aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/sys_windows_arm64.s
AgeCommit message (Collapse)Author
2023-01-25runtime: delete unused cbctxts variable on windows assemblyqmuntal
runtime·cbctxts has been unused since CL 258938, but it was left over. Change-Id: I374ad26e668a36994e41f5d17593b33090bdc644 Reviewed-on: https://go-review.googlesource.com/c/go/+/463119 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-01-24runtime: remove unused badsignal2 on windowsqmuntal
This CL removes badsignal2 function, as it is unused on Windows. badsignal2 was originally intended to abort the process when an exception was raised on a non-Go thread, following the same approach as Linux and others. Since it was added, back on https://golang.org/cl/5797068, it has caused several issues on Windows, see #8224 and #50877. That's because we can't know wether the signal is bad or not, as our trap might not be at the end of the exception handler chain. To fix those issues, https://golang.org/cl/104200046 and CL 442896 stopped calling badsignal2, and CL 458135 removed one last incorrect call on amd64 and 386. Change-Id: I5bd31ee2672118ae0f1a2c8b46a1bb0f4893a011 Reviewed-on: https://go-review.googlesource.com/c/go/+/463116 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-01-24runtime: factor out windows sigtrampqmuntal
This CL factors out part of the Windows sigtramp implementation, which was duplicated in all four architectures. The new common code is implemented in Go rather than in assembly, which will make Windows error handling easier to reason and maintain. While here, implement the control flow guard workaround on windows/386, which almost comes for free. Change-Id: I0bf38c28c54793225126e161bd95527a62de05e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/458135 Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2022-10-19runtime: ignore exceptions from non-Go threads on windows arm/arm64qmuntal
If there is no current G while handling an exception it means the exception was originated in a non-Go thread. The best we can do is ignore the exception and let it flow through other vectored and structured error handlers. I've removed badsignal2 from sigtramp because we can't really know if the signal is bad or not, it might be handled later in the chain. Fixes #50877 Updates #56082 Change-Id: Ica159eb843629986d1fb5482f0b59a9c1ed91698 Reviewed-on: https://go-review.googlesource.com/c/go/+/442896 Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Auto-Submit: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: David Chase <drchase@google.com>
2022-10-12runtime: fix invalid pointer in windows/arm64 badsignal2Bill Zissimopoulos
Initializes the R3 register with an available address in the stack. The addressed location is used to receive the number of bytes written by WriteFile. Fixes #56080 Change-Id: I0368eb7a31d2d6a098fa9c26e074eb1114a92704 GitHub-Last-Rev: 23dbdb53782b38819340ef6609e2c55303eb886d GitHub-Pull-Request: golang/go#56153 Reviewed-on: https://go-review.googlesource.com/c/go/+/442216 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Bryan Mills <bcmills@google.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-03-30runtime: unify C->Go ABI transitions on arm64eric fang
There are several of places that save and restore the C callee-saved registers, the operation is the same everywhere, so this CL defines several macros to do this, which will help reduce code redundancy and unify the operation. This CL also replaced consecutive MOVD instructions with STP and LDP instructions in several places where these macros do not apply. Change-Id: I815f39fe484a9ab9b6bd157dfcbc8ad99c1420fe Reviewed-on: https://go-review.googlesource.com/c/go/+/374397 Trust: Eric Fang <eric.fang@arm.com> Run-TryBot: Eric Fang <eric.fang@arm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2021-11-03runtime: on windows, read nanotime with one instruction or issue barrierJason A. Donenfeld
On 64-bit, this is more efficient, and on ARM64, this prevents the time from moving backwards due to the weaker memory model. On ARM32 due to the weaker memory model, we issue a memory barrier. Updates #48072. Change-Id: If4695716c3039d8af14e14808af217f5c99fc93a Reviewed-on: https://go-review.googlesource.com/c/go/+/361057 Trust: Jason A. Donenfeld <Jason@zx2c4.com> Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2021-06-03[dev.typeparams] runtime: use ABIInternal callbackWrap in callbackasm1 on ARM64Cherry Mui
On Windows/ARM64, callbackasm1 calls callbackWrap via cgocallback. cgocallback uses ABIInternal calling convention to call the function. Pass the ABIInternal entry point to cgocallback. Change-Id: I79d21b77525f6ac8dd50d34f4f304749419b2ad4 Reviewed-on: https://go-review.googlesource.com/c/go/+/324735 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 ABI0 handler addresses on Windows/ARM64Cherry Mui
The handler address is passed to sigtramp, which calls it using ABI0 calling convention. Use ABI0 symbols. Change-Id: I5c16abef5e74a992d972fa5e100fed0ffb9f090a Reviewed-on: https://go-review.googlesource.com/c/go/+/321951 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-04runtime: abort when receiving a signal on a non-Go thread on WindowsMichael Anthony Knyszek
Currently if a signal lands on a non-Go thread that's handled by the Go handler, Go will emit a message. However, unlike everywhere else in the runtime, Go will not abort the process after, and the signal handler will try to continue executing. This leads to cascading failures and possibly even memory corruption. For #45638. Change-Id: I546f4e82f339d555bed295528d819ac883b92bc6 Reviewed-on: https://go-review.googlesource.com/c/go/+/316809 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-04-28runtime: move Windows time.now implementations into separate filesIan Lance Taylor
This is a step toward separating whether time.now is implemented in assembly from whether we are using faketime. Change-Id: I8bf059b44a103b034835e3d3b799319cc05e9552 Reviewed-on: https://go-review.googlesource.com/c/go/+/314273 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-04-28runtime: consolidate Windows time constants into single copyIan Lance Taylor
Change-Id: I1a583d3da9cca4ac51f3fec9b508b7638b452d60 Reviewed-on: https://go-review.googlesource.com/c/go/+/314270 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-04-23runtime: fix windows/arm64 callbackasm1 for frame pointer hackRuss Cox
Fixes the previously failing TestStdcallAndCDeclCallbacks for the 9+ argument case. The last time this code passed, the invisible frame pointer below SP was apparently not enabled on windows/arm64. Change-Id: Ifc3064e894b2f39d6410f3be51c17309ebab08a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/312042 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-04-13runtime: eliminate externalthreadhandlerAustin Clements
This function is no longer used. Eliminating this actually fixes several problems: - It made assumptions about what registers memclrNoHeapPointers would preserve. Besides being an abstraction violation and lurking maintenance issue, this actively became a problem for regabi because the call to memclrNoHeapPointers now happens through an ABI wrapper, which is generated by the compiler and hence we can't easily control what registers it clobbers. - The amd64 implementation (at least), does not interact with the host ABI correctly. Notably, it doesn't save many of the registers that are callee-save in the host ABI but caller-save in the Go ABI. - It interacts strangely with the NOSPLIT checker because it allocates an entire M and G on its stack. It worked around this on arm64, and happened to do things the NOSPLIT checker couldn't track on 386 and amd64, and happened to be *4 bytes* below the limit on arm (so any addition to the m or g structs would cause a NOSPLIT failure). See CL 309031 for a more complete explanation. Fixes #45530. Updates #40724. Change-Id: Ic70d4d7e1c17f1d796575b3377b8529449e93576 Reviewed-on: https://go-review.googlesource.com/c/go/+/309634 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-04-13runtime: use newm for profileloopAustin Clements
This replaces the externalthreadhandler-based implementation of profileloop with one that uses newm to start a new thread. This is a step toward eliminating externalthreadhandler. For #45530. Change-Id: Id8e5540423fe2d2004024b649afec6998f77b092 Reviewed-on: https://go-review.googlesource.com/c/go/+/309633 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-04-13runtime: use compileCallback for ctrlhandlerAustin Clements
This replaces the externalthreadhandler-based implementation of ctrlhandler with one based on compileCallback. This is a step toward eliminating externalthreadhandler. For #45530. Change-Id: I2de2f2f37777af292db67ccf8057b7566aab81f8 Reviewed-on: https://go-review.googlesource.com/c/go/+/309632 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2021-04-12runtime: replace outdated documentation link in Windows' nanotimePaschalis Tsilias
Fixes #45498 Change-Id: I89365f3517bc84376f0f580c64a57f38aaba0cbb Reviewed-on: https://go-review.googlesource.com/c/go/+/308997 Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Alex Brainman <alex.brainman@gmail.com>
2021-03-22runtime: fix bogus NtCurrentTeb()->TlsSlots[n] calculation on windows/arm64Jason A. Donenfeld
runtime.save_g adds X18 to runtime.tls_g in order to have a pointer to thread local storage. X18 represents a pointer to the TEB on ARM64 and runtime.tls_g is set in runtime.wintls at initialization time. This function calls TlsAlloc to allocate a "TLS slot", which is supposed to index into NtCurrentTeb()->TlsSlots. So the full calculation we want is: X18 + offsetof(TEB, TlsSlots) + 8*TlsAllocReturnValue It makes sense to store the complete value of "offsetof(TEB, TlsSlots) + TlsAllocReturnValue" into runtime.tls_g so that the calculation can simplify to: X18 + runtime.tls_g But, instead of computing that, we're currently doing something kind of strange, in which we: - call TlsAlloc, which puts its return value into X0 - make sure X0 is less than 64, so we don't overflow - set runtime.tls_g to 8*X1 + offsetof(TEB, TlsSlots) The question is: why are we using X1 instead of X0? What is in X1? Probably it was, by luck, zero before, and TlsAlloc returned zero, so there was no problem. But on recent versions of Windows, X1 is some other garbage value and not zero, so we eventually crash when trying to dereference X18 + runtime.tls_g. This commit fixes the problem by just computing: runtime.tls_g = 8*X0 + offsetof(TEB, TlsSlots) Fixes #45138. Change-Id: I560426bae7468217bd183ac6c6eb4b56a3815b09 Reviewed-on: https://go-review.googlesource.com/c/go/+/303273 Trust: Jason A. Donenfeld <Jason@zx2c4.com> Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-03-19runtime: mark Windows' address-taken asm routines as ABIInternalMichael Anthony Knyszek
In the runtime there are Windows-specific assembly routines that are address-taken via funcPC and are not intended to be called through a wrapper. Mark them as ABIInternal so that we don't grab the wrapper, because that will break in all sorts of contexts. For #40724. For #44065. Change-Id: I12a728786786f423e5b229f8622e4a80ec27a31c Reviewed-on: https://go-review.googlesource.com/c/go/+/302109 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: convert windows/arm64 assemblyRuss Cox
The assembly is mostly a straightforward conversion of the equivalent arm assembly. This CL is part of a stack adding windows/arm64 support (#36439), intended to land in the Go 1.17 cycle. Change-Id: I61b15d712ade4d3a7285c7680de8e0987aacba10 Reviewed-on: https://go-review.googlesource.com/c/go/+/288828 Trust: Russ Cox <rsc@golang.org> Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-02-19runtime: initial windows/arm64 implementation filesRuss Cox
This CL adds a few small files - defs, os, and rt0 - to start on windows/arm64 support for the runtime. It also copies sys_windows_arm.s to sys_windows_arm64.s, with the addition of "#ifdef NOT_PORTED" around the entire file. This is meant to make future CLs easier to review, since the general pattern is to translate the 32-bit ARM assembly into 64-bit ARM assembly. This CL is part of a stack adding windows/arm64 support (#36439), intended to land in the Go 1.17 cycle. Change-Id: I922037eb3890e77bac48281ecaa8e489595675be Reviewed-on: https://go-review.googlesource.com/c/go/+/288827 Trust: Russ Cox <rsc@golang.org> Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>