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: PC values from Callers do not correspond to symbol table on Darwin #45853
Comments
Doesn't work at all on darwin/amd64. Binaries are macho, not elf. What are darwin/arm64 binaries? |
I linked to the corresponding darwin program above: https://play.golang.org/p/tOBx2Bvl5VA. I elided error handling for simplicity, that's not the source of the issue. |
@heschi suggested it might be due to ASLR. If that is the case, is it possible to determine some constant symbol table-offset that is ASLR-independent? |
No, I hadn't seen the actual values in question. That's not ASLR. |
Ok, sorry I didn't realize those were two separate programs. It works on darwin/amd64. If it is ASLR, it should report a different PC on each run. Does it? (On amd64 it doesn't.) |
Also, if it is ASLR you should be able to check two different functions and see if the error delta is the same. |
Yes, on darwin/arm64 everything must be PIE. It is ASLR. |
On other platforms if you used -buildmode=pie, you will see similar results. As @randall77 said, you can check for address differences. I'm not sure if there is anything else we could do. Thanks. |
Thanks, that makes sense. I did some playing around and it seems that taking the address of the text segment at runtime and computing When playing with this I noticed the runtime looks this up using in the |
Yes, that should work. (But see below.)
In a standard executable there should only be one module. You'll get more than one module only if you use the plugin package, or use other alternate linking modes. In those cases, yes, you would need to resolve the module first (because there would be multiple text segments in your address space). I'm going to close, there's no bug in Go here. |
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?
I called
runtime.Callers
and tried to match the PCs with the information in the symbol table (usingdebug/macho
anddebug/gosym
).This program works as expected on linux: https://play.golang.org/p/p8KzmTQw_WQ
What did you expect to see?
I expected similar output to the linux version.
What did you see instead?
On darwin/arm64 (https://play.golang.org/p/tOBx2Bvl5VA):
The text was updated successfully, but these errors were encountered: