Fix pmcstat symbol resolution for userland processes

[stas]

Summary

Under certain pmcstat(8) fails to resolve symbols for userland processes which are already running by the time pmcstat launches.

This happens because pmcstat(8) miscalculates virtual address of the code section of the loaded image.
This has no effect on the symbol resolution for the newly launched programs as the same value passed
to the pmcstat_image_link() function as the 'start' argument, so the offset ends up being zero. However,
for existing processes the correct value is getting passed, so offset becomes invalid and the start and
end values of the code segments receive invalid values.

Work this around by ignoring non-executable sections of the ELF file. A real fix is more complicated
as ELF file can contain multiple code segments and all of them need to be handled properly. But
this should solve the problem for majority of cases for now.

Test Plan

Verified that pmcstat -T and pmcstat -G works correctly now. Also made sure that image
sections layout pmcstat(8) builds is now correct.

[stas]

With this change pmcstat(8) still does not resolve symbols for some applications, but at least they show up in pmcstat -T and in the callgraph (before that pmcstat would mark their frames as "dubious").

[stas]

Example running unixbench:

%SAMP IMAGE      FUNCTION             CALLERS
 23.6 whetstone- p3                   whetstones
 18.5 libm.so.5  exp                  whetstones
 18.5 libm.so.5  log                  whetstones
 13.6 whetstone- whetstones           main
  9.0 whetstone- po                   whetstones
  2.3 whetstone- pa                   whetstones
  2.0 libm.so.5  0x1c270              cos
  2.0 kernel     __mnt_vnode_next_all vfs_stdsync
  1.3 libm.so.5  0x1c374              whetstones
  1.3 libm.so.5  0x1c354              whetstones
  1.2 libm.so.5  0x1c370              whetstones
  1.2 libm.so.5  0x1c33c              whetstones

[jhb]

Ok. I think the longer term fix is to update the MAP_IN message to include the relative offset of the mapping to the backing object, then it wouldn't have to parse the header to see what offset of the file is mapped.

[stas]

In D2518#46456, @jhb wrote:

Ok. I think the longer term fix is to update the MAP_IN message to include the relative offset of the mapping to the backing object, then it wouldn't have to parse the header to see what offset of the file is mapped.

That's what I was thinking as well. Will look at that next.

[rpaulo]

usr.sbin/pmcstat/pmcstat_log.c

719

This probably goes beyond 80 columns. (I can't tell.)

[stas]

This was submitted as r282866.

usr.sbin/pmcstat/pmcstat_log.c

719

You are correct of course. Thanks.