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

runtime: use register instead of TLS for G pointer for darwin/arm and darwin/arm64 #24793

Open
randall77 opened this Issue Apr 10, 2018 · 7 comments

Comments

Projects
None yet
5 participants
@randall77
Contributor

randall77 commented Apr 10, 2018

Need to decide how to handle TLS on darwin/arm. On x86, TLS was moved from a pthread_get/setspecific implementation to a reserved (by Apple) slot in the TLS (see #23617). That's not possible for arm/arm64 so we still use the old method. Since these archs have more registers, we should probably just reserve a register for the G pointer.

Reserving a register might invalidate some existing assembly code. Kind of a wrench in the plan, need to investigate how bad it might be.

Or maybe someone can think of a better solution.

We might need a solution before we can do #17490 for arm.

@randall77 randall77 added the OS-Darwin label Apr 10, 2018

@randall77 randall77 added this to the Go1.12 milestone Apr 10, 2018

@cherrymui

This comment has been minimized.

Contributor

cherrymui commented Apr 10, 2018

I think we already do reserve a G register on ARM and ARM64, regardless of OS. This is R10 on ARM, and R28 on ARM64. TLS is only used when crossing Go-C boundary, where we save G register to a TLS slot when calling to C, and reload it when entering Go code, as C code may clobber our G register.

@randall77

This comment has been minimized.

Contributor

randall77 commented Apr 10, 2018

Maybe this is unnecessary then.

@eliasnaur

This comment has been minimized.

Contributor

eliasnaur commented Apr 10, 2018

The pthread_get/set magic is still present in runtime/cgo/gcc_darwin_arm*.c so I wouldn't qualify that as unnecessary.

@cherrymui given that we only use the TLS slot for Cgo, could we use a callee-saved register for G and thus avoid the TLS slot (and the save/restore) altogether?

@cherrymui

This comment has been minimized.

Contributor

cherrymui commented Apr 10, 2018

I haven't looked into the code in detail, but I'm not sure callee-saved register is enough. C code can still temporarily use the register, and a signal can happen at this point. The signal handler, runtime.sigtramp needs to look at the G register to tell whether/which Go stack we are on.

@bcmills

This comment has been minimized.

Member

bcmills commented Apr 10, 2018

Backing up one level: why does runtime.sigtramp need to know which goroutine is running if we're in a C call?

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 11, 2018

I'm not sure I completely understand the question, but see the sigtramp code in runtime/sys_darwin_arm.s and runtime/sys_darwin_arm64.s. It does today examine the g register, which it loads out of the TLS slot.

@cherrymui

This comment has been minimized.

Contributor

cherrymui commented Apr 11, 2018

Besides signal handler, another place where we need G is when Go calls C which calls back to Go. There we want to use the same G, I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment