Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

runtime: always set up TLS on all G-register architectures? #35853

Open
cherrymui opened this issue Nov 26, 2019 · 4 comments
Open

runtime: always set up TLS on all G-register architectures? #35853

cherrymui opened this issue Nov 26, 2019 · 4 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Unplanned

Comments

@cherrymui
Copy link
Member

Currently, on G-register architectures (i.e. all non-x86), we set up TLS only when cgo is used, by libc. The reason is probably that the G register is reserved in Go code and so it should always be valid. However, there are more and more cases where we call external functions even in a non-cgo program, for example, VDSO, and libc calls on darwin. These external functions could potentially clobbers the G register temporarily. If a signal is received during the execution of an external function, we cannot directly use the G register's content as the G. This has caused a number of problems. Currently we play various tricks and workarounds. See e.g. #32912, #34391, #35800.

Maybe we should consider initializing TLS ourselves in non-cgo programs, and always save/restore G in TLS across external calls? This way, we unify the cgo and non-cgo code paths, and can remove various workarounds and maybe potential problems.
@cherrymui cherrymui added this to the Go1.15 milestone Nov 26, 2019
@dmitshur dmitshur added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Nov 26, 2019
@gopherbot
Copy link

Change https://golang.org/cl/209197 mentions this issue: runtime: always set up TLS storage for darwin/arm64

@odeke-em
Copy link
Member

We didn't cover ground for Go1.15, and Elias ran out of time in CL 209197, thus I shall move this issue to Go1.16.

@odeke-em odeke-em modified the milestones: Go1.15, Go1.16 May 31, 2020
@gopherbot
Copy link

Change https://golang.org/cl/265118 mentions this issue: runtime: set up TLS without cgo on darwin/arm64

gopherbot pushed a commit that referenced this issue Oct 28, 2020
@cherrymui
runtime: set up TLS without cgo on darwin/arm64
72dec90 
Currently, on darwin/arm64 we set up TLS using cgo. TLS is not
set for pure Go programs. As we use libc for syscalls on darwin,
we need to save the G register before the libc call. Otherwise it
is not signal-safe, as a signal may land during the execution of
a libc function, where the G register may be clobbered.

This CL initializes TLS in Go, by calling the pthread functions
directly without cgo. This makes it possible to save the G
register to TLS in pure Go programs (done in a later CL).

Inspired by Elias's CL 209197. Write the logic in Go instead of
assembly.

Updates #38485, #35853.

Change-Id: I257ba2a411ad387b2f4d50d10129d37fec7a226e
Reviewed-on: https://go-review.googlesource.com/c/go/+/265118
Trust: Cherry Zhang <cherryyz@google.com>
Trust: Elias Naur <mail@eliasnaur.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@cherrymui cherrymui modified the milestones: Go1.16, Unplanned Dec 3, 2020
@cherrymui
Copy link
Member Author

I did this for darwin/arm64 (including ios) in Go 1.16. I don't think we'll do any other in Go 1.16. This is still probably a good idea, but I don't think I have plan to do it any time soon.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@dmitshur @odeke-em @gopherbot @cherrymui