-
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: the value stored in pcHeader in runtime.firstmoduledata
is different from runtime.pclntab
when using external links on macOS arm64 cgo
#69428
Comments
This is an advisory issue rather than a bug, as it doesn't seem to affect the operation of the Go binary. |
CC @cherrymui @golang/runtime |
I think the moduledata references pcheader with a dynamic relocation (or the equivalent on Mach-O, a "bind" or "rebase" entry). The data you read directly from moduledata is without the relocation applied. You'll need to decode and apply the relocation. It is possible that the Go linker and C linker (or even different versions of the C linker) use different relocation mechanism, and the pre-relocated data may or may not be meaningful. They are semantically equivalent so at program run time it always point to the right data. I'm not sure if there is anything we can do. |
If that's the reason, I'm wondering why buildmode being exe or pie doesn't change this behaviour. I looked up some other issues, is it because Apple doesn't support generating non-pie binaries anymore either? |
That is correct. Again, the un-relocated data varies depending on architecture, link mode, linker version, etc.. It may happen to be useful, or not. |
I investigated the issue further and it doesn't seem to be a relocation issue, please check the attached image, the corresponding sections for This can also be verified by
|
Mach-O doesn't use relocations in that sense. They have "rebase" and "bind" tables instead. Try |
For a binary I built, I have
The rebase entry does point to the right address. As you mentioned above, this is not a bug. And I don't think there is much we can do. Thanks. |
Thanks for the suggestion. But I tried https://github.com/Zxilly/go-testdata/releases/download/latest/bin-darwin-1.23-arm64-strip-pie-cgo Can you please suggest me some other directions? I got
on this file. |
I guess it was related to |
You're probably right that chained fixups are related. That is yet another way of expressing dynamic relocations in Mach-O. |
Go version
go version devel go1.24-2a10a5351b Wed Aug 14 12:32:08 2024 +0800 windows/amd64
Output of
go env
in your module/workspace:What did you do?
I'm trying to extract the
moduledata.pcHeader
value from the binaries, and the integration test shows this error since go1.21 release.Prior to go 1.21, the runtime.text symbol would still be present in the binary even if the -s flag was passed, masking the problem.
What did you see happen?
the value stored in pcHeader in
runtime.firstmoduledata
is different fromruntime.pclntab
when using external links onmacOS arm64 cgo
Can be reproduced with the following code:
Will results to
Some scripts indicates similiar problem on most recent major Go releases:
This only happens on
macOS arm64
with external link.Here's some binary as input:
https://github.com/Zxilly/go-testdata/releases/download/latest/bin-darwin-1.22-arm64-strip-cgo
https://github.com/Zxilly/go-testdata/releases/download/latest/bin-darwin-1.22-arm64-strip-pie-cgo
https://github.com/Zxilly/go-testdata/releases/download/latest/bin-darwin-1.23-arm64-strip-cgo
https://github.com/Zxilly/go-testdata/releases/download/latest/bin-darwin-1.23-arm64-strip-pie-cgo
What did you expect to see?
These value should keep same as other arch.
The text was updated successfully, but these errors were encountered: