libpmcstat: Teach pmcstat_image_get_elf_params about debug files

[jrtc27]

Summary

libpmcstat scans the image (executable or library) for symbol tables in
order to be able to symbolicate callgraphs. However, we strip objects by
default, relying on separate debug files in /usr/lib/debug to provide
full symbol information to debuggers, and libpmcstat does not scan these
currently (though pmcstat itself does for other purposes). Thus, fix
this deficiency by also scanning a corresponding debug file, should it
exist, for symbols. This makes system-wide profiling of base much more
useful.

MFC after: 1 month

[jhb]

Oh, humm. We should probably be honoring the debug link (.gnu_debuglink section). Fix the kernel modules path thing would avoid a combinatorics explosion here since you would just have the !kernel-modules case to deal with. What GDB does when looking for separate files is something like this:

• debug_file = read_section('.gnu_debuglink')
• check dirname(executable) + debug_file
• check /usr/lib/debug + dirname(executable) + debug_file

Checking the link would fix the problem you ran into with hardlinks (clang vs clang++, etc.) since the link would always be "clang.debug".

[jrtc27]

In D39626#902584, @jhb wrote:

Oh, humm. We should probably be honoring the debug link (.gnu_debuglink section). Fix the kernel modules path thing would avoid a combinatorics explosion here since you would just have the !kernel-modules case to deal with. What GDB does when looking for separate files is something like this:

• debug_file = read_section('.gnu_debuglink')
• check dirname(executable) + debug_file
• check /usr/lib/debug + dirname(executable) + debug_file

Checking the link would fix the problem you ran into with hardlinks (clang vs clang++, etc.) since the link would always be "clang.debug".

That does indeed sound nicer, and explains why we don't need to have /usr/lib/debug links with GDB.

[jrtc27]

In-progress rework to use .gnu_debuglink, but that requires no ABI changes, especially not to the kernel