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

runtime: delete unused cbctxts variable on windows assembly

2023-01-25T22:05:14Z

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 Reviewed-by: Bryan Mills Run-TryBot: Quim Muntal Reviewed-by: Cherry Mui

runtime: remove unused badsignal2 on windows

2023-01-24T12:56:06Z

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 Run-TryBot: Quim Muntal Reviewed-by: Alex Brainman Reviewed-by: Cherry Mui TryBot-Result: Gopher Robot

runtime: factor out windows sigtramp

2023-01-24T12:05:07Z

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 Reviewed-by: Cherry Mui Reviewed-by: Alex Brainman TryBot-Result: Gopher Robot Reviewed-by: Bryan Mills Reviewed-by: Michael Pratt

runtime,cmd/internal/obj/x86: use TEB TLS slots on windows/i386

2023-01-23T18:15:35Z

This CL redesign how we get the TLS pointer on windows/i386. It applies the same changes as done in CL 431775 for windows/amd64. We were previously reading it from the [TEB] arbitrary data slot, located at 0x14(FS), which can only hold 1 TLS pointer. With this CL, we will read the TLS pointer from the TEB TLS slot array, located at 0xE10(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: 0xE10 + index*4. 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(FS), AX Notice that this approach will now be implemented in all the supported windows arches. [TEB]: https://en.wikipedia.org/wiki/Win32_Thread_Information_Block [TlsAlloc]: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsalloc Change-Id: If4550b0d44694ee6480d4093b851f4991a088b32 Reviewed-on: https://go-review.googlesource.com/c/go/+/454675 Reviewed-by: Michael Pratt Run-TryBot: Quim Muntal Reviewed-by: Cherry Mui TryBot-Result: Gopher Robot

[dev.typeparams] runtime: use internal/abi.FuncPCABI0 to take address of assembly functions

2021-05-21T21:52:38Z

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 Run-TryBot: Cherry Mui TryBot-Result: Go Bot Reviewed-by: Michael Knyszek

runtime: abort when receiving a signal on a non-Go thread on Windows

2021-05-04T21:16:16Z

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 Run-TryBot: Michael Knyszek Reviewed-by: Cherry Zhang

runtime: move Windows time.now implementations into separate files

2021-04-28T20:16:36Z

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 Run-TryBot: Ian Lance Taylor Reviewed-by: Michael Knyszek

runtime: consolidate Windows time constants into single copy

2021-04-28T15:58:43Z

Change-Id: I1a583d3da9cca4ac51f3fec9b508b7638b452d60 Reviewed-on: https://go-review.googlesource.com/c/go/+/314270 Trust: Ian Lance Taylor Run-TryBot: Ian Lance Taylor Reviewed-by: Michael Knyszek

runtime: eliminate externalthreadhandler

2021-04-13T21:13:12Z

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 Run-TryBot: Austin Clements TryBot-Result: Go Bot Reviewed-by: Michael Pratt Reviewed-by: Michael Knyszek

runtime: use newm for profileloop

2021-04-13T21:13:11Z

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 Run-TryBot: Austin Clements TryBot-Result: Go Bot Reviewed-by: Michael Pratt Reviewed-by: Michael Knyszek