Skip to content

runtime: build broken for arm devices < ARMv7 #8690

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.

Sign up for GitHub

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
Closed
davecheney opened this issue Sep 10, 2014 · 10 comments
Closed

runtime: build broken for arm devices < ARMv7 #8690

davecheney opened this issue Sep 10, 2014 · 10 comments
Labels
FrozenDueToAge
Milestone
Go1.4

Comments

@davecheney
Copy link
Contributor 

What steps will reproduce the problem?

CL 135570043 / 956f9d3f0fcf changed the way g is stored into a TLS slot. This seems to
have broken the ARMv5 build, and likely the ARMv6 build (Raspberry Pi)

What is the expected output? What do you see instead?

The builders timeout in odd ways

ARM5: http://build.golang.org/log/a3746142002541c08793826afeb6959cfdcc9222
ARM6: http://build.golang.org/log/d92bf568014f5c6844024307dd0c464d86196cd8

On my ARM5 system I found a bunch of `go env` processes spinning at 100%

Please use labels and text to provide additional information.

From CL 135570043

The build just appears to hand during compilation of text/scanner,
hitting the build process (the parent cmd/go) with a signal gives

dfc@qnap:~/go/src$ fg
./all.bash
^\SIGQUIT: quit
PC=0xa7810

goroutine 1 [running]:
runtime.save_g(0x107020c0)
/home/dfc/go/src/runtime/tls_arm.s:36 +0x8 fp=0xbebd66d0 sp=0xbebd66d0
schedule()
/home/dfc/go/src/runtime/proc.c:1664 +0x268 fp=0xbebd671c sp=0xbebd66d0
schedule()
/home/dfc/go/src/runtime/proc.c:1664 +0x268 fp=0xbebd6768 sp=0xbebd671c

trap    0x6
error   0x0
oldmask 0x0
r0      0x107020b0
r1      0x107020c0
r2      0x0
r3      0x107020b0
r4      0x0
r5      0x1
r6      0x107020b0
r7      0x0
r8      0x0
r9      0x0
r10     0x107020b0
fp      0x8
ip      0xbebd6715
sp      0xbebd66d0
lr      0xa780c
pc      0xa7810
cpsr    0x20000010
fault   0x0
@davecheney
Copy link
Contributor Author

Comment 1:

@minux, I think the special case added in
https://code.google.com/p/go/source/detail?r=fda4c0d14c53 isn't firing properly after
this change. Do you have time to take a look ?

@davecheney
Copy link
Contributor Author

Comment 2:

I've confirmed this affects platforms for GOARM < 7, the ones that use
read_tls_fallback.
You can reproduce the problem on your (any) arm host 
env GOARM=5 ./all.bash, will hang shortly after go_bootstrap starts to run.

@davecheney
Copy link
Contributor Author

Comment 3:

Is this as simple as we need to implement a version of write_tls_fallback for ARM
systems < ARMv7 ?

Status changed to Accepted.

@gopherbot
Copy link
Contributor

Comment 4:

CL https://golang.org/cl/143850043 mentions this issue.

@gopherbot
Copy link
Contributor

Comment 5:

CL https://golang.org/cl/143050043 mentions this issue.

@minux
Copy link
Member

minux commented Sep 15, 2014

Comment 6:

i wonder if we should make a more robust version of tls fallback function that
saves all registers to g->m?

@rsc
Copy link
Contributor

rsc commented Sep 18, 2014

Comment 7:

saving all registers is unnecessary. there are only a few call sites.

@davecheney
Copy link
Contributor Author

Comment 8:

This issue was updated by revision 66795e8.

If liblink determines that the host doesn't support TLS it replaces the MRC call with a
BL runtime.tls_read_fallback. The problem is save_g doesn't expect anyone to make any BL
calls and hasn't setup its own link register properly so when runtime.tls_read_fallback
returns the LR points to save_g, not save_g's caller so the RET at the end of the
function turns into an infinite loop.
This fix is only a proof of concept, I think the real fix should go into liblink as its
MRC substitution is not as transparent as expected.
LGTM=rsc
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/143050043

@gopherbot
Copy link
Contributor

Comment 9:

CL https://golang.org/cl/147310043 mentions this issue.

@davecheney
Copy link
Contributor Author

Comment 10:

This issue was closed by revision 0b36211.

Status changed to Fixed.

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@rsc rsc removed the release-go1.4 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
@davecheney @wheatman
liblink: generate MRC replacement in liblink, not tls_arm
cdd7d67 
Fixes golang#8690.

This CL moves the save of LR around BL runtime.read_tls_fallback to liblink as it is not needed when MRC is not replaced.

LGTM=rsc, minux
R=rsc, khr, minux
CC=golang-codereviews
https://golang.org/cl/147310043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 26, 2018
@davecheney @wheatman
liblink: generate MRC replacement in liblink, not tls_arm
76aca6b 
Fixes golang#8690.

This CL moves the save of LR around BL runtime.read_tls_fallback to liblink as it is not needed when MRC is not replaced.

LGTM=rsc, minux
R=rsc, khr, minux
CC=golang-codereviews
https://golang.org/cl/147310043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
@davecheney @wheatman
liblink: generate MRC replacement in liblink, not tls_arm
4020dd5 
Fixes golang#8690.

This CL moves the save of LR around BL runtime.read_tls_fallback to liblink as it is not needed when MRC is not replaced.

LGTM=rsc, minux
R=rsc, khr, minux
CC=golang-codereviews
https://golang.org/cl/147310043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 30, 2018
@davecheney @wheatman
liblink: generate MRC replacement in liblink, not tls_arm
4618854 
Fixes golang#8690.

This CL moves the save of LR around BL runtime.read_tls_fallback to liblink as it is not needed when MRC is not replaced.

LGTM=rsc, minux
R=rsc, khr, minux
CC=golang-codereviews
https://golang.org/cl/147310043
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.4
Development

No branches or pull requests
4 participants
@davecheney @rsc @minux @gopherbot