-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/link: fix deferreturn detector #32477
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
Comments
Change https://golang.org/cl/181258 mentions this issue: |
@gopherbot, please open a backport to 1.12. |
Backport issue(s) opened: #32484 (for 1.12). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
Change https://golang.org/cl/181378 mentions this issue: |
…ack"" This reverts CL 180761 Reason for revert: Reinstate the stack-allocated defer CL. There was nothing wrong with the CL proper, but stack allocation of defers exposed two other issues. Issue #32477: Fix has been submitted as CL 181258. Issue #32498: Possible fix is CL 181377 (not submitted yet). Change-Id: I32b3365d5026600069291b068bbba6cb15295eb3 Reviewed-on: https://go-review.googlesource.com/c/go/+/181378 Reviewed-by: Brad Fitzpatrick <[email protected]>
The logic for detecting deferreturn calls is wrong.
We look for a relocation whose symbol is
runtime.deferreturn
and has an offset of 0. But on some architectures, the relocation offset is not zero. These include arm (the offset is 0xebfffffe) and s390x (the offset is 6).This ends up having the deferreturn offset at 0, so we end up using the entry point live map instead of the deferreturn live map in a frame which defers and then segfaults.
Update #6980
The text was updated successfully, but these errors were encountered: