Note that all the non-Linux systems have this problem, and that the problem only affects fetching symbol information for dynamic libraries the binary is linked against, not the main binary.
For macOS in particular, from searching around it seems that /usr/bin/vmmap is the suggested way to get that information, and it is in turn implemented using mach_vm_region_recurse. However, vmmap asks to be root to run. I don't know of mach_vm_region_recurse on our own process will require root privileges or not. If it does, that's a non-starter.
Profile's Mapping field is currently populated by reading /proc/self/maps.
On systems where /proc/self/maps is not available, the profile generated
by Go's runtime will not have any Mapping entry. Pprof command then adds
a fake entry and links all Location entries in the profile with the fake
entry to be used during symbolization.
The fake entry is not enough to suppress the error or warning messages
pprof command produces. We need to tell pprof that Location entries are
symbolized already by Go runtime and pprof does not have to attempt to
perform further symbolization.
In #25743, we made Go runtime mark Mapping entries with HasFunctions=true
when all Location entries from the Mapping entries are successfully
symbolized. This change makes the Go runtime add a fake mapping entry,
otherwise the pprof command tool would add, and set the HasFunctions=true
following the same logic taken when the real mapping information is
Fixes#26255. Tested pprof doesn't report the error message any more
for pure Go program.
Run-TryBot: Hyang-Ah Hana Kim <email@example.com>
TryBot-Result: Gobot Gobot <firstname.lastname@example.org>
Reviewed-by: Brad Fitzpatrick <email@example.com>