Doesn't work at all on darwin/amd64. Binaries are macho, not elf. What are darwin/arm64 binaries?
You should check the error result of elf.NewFile regardless.

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.

I expected similar output to the linux version.

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 PC - textSegmentAddr should produce a constant offset that can be looked up in the symbol table (by adding it with the static text segment address). Does that make sense?

When playing with this I noticed the runtime looks this up using in the moduledata struct, and it's a linked list starting at firstmoduledata. Am I understanding it correctly that I should be able to do this using firstmoduledata.text in all circumstances, or do I need to resolve the appropriate module for each PC to do this sort of mapping?

Thanks, that makes sense. I did some playing around and it seems that taking the address of the text segment at runtime and computing PC - textSegmentAddr should produce a constant offset that can be looked up in the symbol table (by adding it with the static text segment address). Does that make sense?

Yes, that should work. (But see below.)

When playing with this I noticed the runtime looks this up using in the moduledata struct, and it's a linked list starting at firstmoduledata. Am I understanding it correctly that I should be able to do this using firstmoduledata.text in all circumstances, or do I need to resolve the appropriate module for each PC to do this sort of mapping?

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.