Page MenuHomeFreeBSD

Fix pmcstat symbol resolution for userland processes
ClosedPublic

Authored by stas on May 12 2015, 7:06 AM.
Tags
Referenced Files
Unknown Object (File)
Dec 19 2023, 11:57 PM
Unknown Object (File)
Nov 23 2023, 7:00 PM
Unknown Object (File)
Nov 21 2023, 12:46 PM
Unknown Object (File)
Oct 27 2023, 11:05 PM
Unknown Object (File)
Oct 25 2023, 3:36 PM
Unknown Object (File)
Oct 21 2023, 2:23 AM
Unknown Object (File)
Oct 13 2023, 2:00 PM
Unknown Object (File)
Aug 21 2023, 3:53 PM
Subscribers

Details

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.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

stas retitled this revision from to Fix pmcstat symbol resolution for userland processes.
stas updated this object.
stas edited the test plan for this revision. (Show Details)
stas added reviewers: adrian, ganbold, jhb.
stas set the repository for this revision to rS FreeBSD src repository - subversion.
stas added a project: pmc.

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").

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

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.

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.

Macro bulbasaur:
Macro rubberstamp:

usr.sbin/pmcstat/pmcstat_log.c
719

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

Macro bikeshed:

rpaulo edited edge metadata.
This revision is now accepted and ready to land.May 13 2015, 4:31 AM
stas marked an inline comment as done.

This was submitted as r282866.

usr.sbin/pmcstat/pmcstat_log.c
719

You are correct of course. Thanks.