cc: Retry symbol resolution using perfmap
When a symbol lies within a module, and that module doesn't have debuginfo (or doesn't even have an ELF header), the symbol will always be resolved as [unknown]. However, the /tmp/perf-PID.map (perf map) for that process might actually have an entry for that symbol, if it was dynamically generated by some external tool. This commit changes the resolution process such that if the desired address lies in a module but that module doesn't have debuginfo, we keep trying to resolve it in subsequent modules (including the perf map). If we resolve it successfully using the perf map, the reported symbol information will have the original module's name, so we don't lose fidelity. The motivation for this change is the way symbols work with .NET Core on Linux. The runtime binaries are compiled ahead-of-time to native code, but do not have debuginfo. There is an external tool, which generates a file similar to a perf map (albeit with relative addresses) for these binaries. This file can then be merged into the main perf map for the process and used for symbol resolution, but only if we keep trying to use the perf map when the symbol is in a previously-seen module.
Showing
Please register or sign in to comment