-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/link: Trampoline insertion breaks DWARF Line Program Table output on Darwin/ARM64 #54320
Comments
Your patch looks good to me. Looks like the PR is blocked due to CLA, but I'm happy to review when it arrives in Gerrit. |
I think you can just call Also, see https://go.dev/doc/contribute for how to contribute to Go. We cannot do code review on GitHub. Thanks. |
Change https://go.dev/cl/422154 mentions this issue: |
When trampolines are needed (e.g. Darwin ARM64), the DWARF LPT (Line Program Table - see DWARF section 6.1) generation fails because the replacement symbols are marked as external symbols and skipped during the DWARF LPT generation phase. This PR is still subject to extensive testing but has rectified the issue for the very large binaries we link at Uber. Fixes golang#54320
When trampolines are needed (e.g. Darwin ARM64), the DWARF LPT (Line Program Table - see DWARF section 6.1) generation fails because the replacement symbols are marked as external symbols and skipped during the DWARF LPT generation phase. This PR is still subject to extensive testing but has rectified the issue for the very large binaries we link at Uber. Fixes golang#54320
When trampolines are needed (e.g. Darwin ARM64), the DWARF LPT (Line Program Table - see DWARF section 6.1) generation fails because the replacement symbols are marked as external symbols and skipped during the DWARF LPT generation phase. Fixes golang#54320
This seems like we also need a backport issue for 1.18. Please close the backport issue if it isn't the case. |
@gopherbot please open a backport to 1.18. |
Backport issue(s) opened: #54502 (for 1.18). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
is this darwin/arm64 only, or linux/arm64 too? |
Technically it includes linux/arm64 as well. But generally one would not build programs with This bug does not affect the correctness of the program, only debug info generation. |
This affects all trampoline architectures. Internally at Uber, we are seeing many SWEs on Apple M1 setups unable to practically debug (line level step through) Go programs that are statically linked over 124MB, which is the trampoline size for Darwin/ARM64. The debugtramp=2 is just a trivial way to reproduce this. We see real world binaries linked without special flags that require linker trampolines being affected. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
$go build -ldflags '-debugtramp=2'
What did you expect to see?
What did you see instead?
Line information is removed.
Anaylsis
The trampoline path in the linker turns internal symbols (cloneToExternal) that are trampolined into external symbols.
Now, the DWARF generation code, e.g. in writelines skips over external symbols with the explicit stated assumption that they would never have auxsyms, which is not true for trampolines.
Indeed, this proof of concept change test appears to fix the problem
master...jquirke:go:Linker_DWARF
Comments
Although the repro forces trampolines; there are many ARM64 binaries at Uber that require relocations more than +/- 124MB, and thus are not debuggable
The text was updated successfully, but these errors were encountered: