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

runtime: "morestack on g0" in x/perf/storage/app on windows/arm64 [1.17 backport] #49479

Closed
gopherbot opened this issue Nov 9, 2021 · 6 comments
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge release-blocker
Milestone

Comments

@gopherbot
Copy link

@bcmills requested issue #47557 to be considered for backport to the next 1.17 minor release.

@gopherbot, please backport to Go 1.17. This failure mode is still occurring consistently on the go1.17 builder.

@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Nov 9, 2021
@gopherbot gopherbot added this to the Go1.17.4 milestone Nov 9, 2021
@bcmills
Copy link
Contributor

bcmills commented Nov 9, 2021

It isn't clear to me whether any Go 1.17 users are affected by this bug, but we shouldn't be cutting releases with known-failing builders (#11811), and the patch seems small and low-risk anyway.

@TopperDEL
Copy link

I would indeed be one of those being happy about a backport - if that means the fix would be available in go1.17. I'm not used to the term "backport" here. :)

@cagedmantis
Copy link
Contributor

This backport request has been approved as it is a serious issue without a viable workaround.

@cagedmantis cagedmantis added the CherryPickApproved Used during the release process for point releases label Nov 10, 2021
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Nov 10, 2021
@gopherbot
Copy link
Author

Change https://golang.org/cl/363014 mentions this issue: [release-branch.go1.17] cmd/link: don't use label symbol for absolute address relocations on ARM64 PE

@gopherbot
Copy link
Author

Closed by merging b954f58 to release-branch.go1.17.

gopherbot pushed a commit that referenced this issue Nov 10, 2021
… address relocations on ARM64 PE

On ARM64 PE, when external linking, the PE relocation does not
have an explicit addend, and instead has the addend encoded in
the instruction or data. An instruction (e.g. ADRP, ADD) has
limited width for the addend, so when the addend is large we use
a label symbol, which points to the middle of the original target
symbol, and a smaller addend. But for an absolute address
relocation in the data section, we have the full width to encode
the addend and we should not use the label symbol. Also, since we
do not adjust the addend in the data, using the label symbol will
actually make it point to the wrong address. E.g for an R_ADDR
relocation targeting x+0x123456, we should emit 0x123456 in the
data with an IMAGE_REL_ARM64_ADDR64 relocation pointing to x,
whereas the current code emits  0x123456 in the data with an
IMAGE_REL_ARM64_ADDR64 relocation pointing to the label symbol
x+1MB, so it will actually be resolved to x+0x223456. This CL
fixes this.

Fixes #49479

Change-Id: I64e02b56f1d792f8c20ca61b78623ef5c3e34d7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360895
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit 988efd5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/363014
Run-TryBot: Carlos Amedee <carlos@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
@TopperDEL
Copy link

This made my project working - thanks again to everybody having being involved here!

@golang golang locked and limited conversation to collaborators Dec 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge release-blocker
Projects
None yet
Development

No branches or pull requests

4 participants