Page MenuHomeFreeBSD

Fix pmcstat symbol resolution for userland processes
ClosedPublic

Authored by stas on May 12 2015, 7:06 AM.

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
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

stas updated this revision to Diff 5334.May 12 2015, 7:06 AM
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.
stas added a project: pmc.
stas added a reviewer: rpaulo.May 12 2015, 7:09 AM
stas added a comment.May 12 2015, 7:30 AM

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 added a comment.EditedMay 12 2015, 7:53 AM

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 edited edge metadata.May 12 2015, 12:15 PM

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 added a comment.May 12 2015, 7:40 PM
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 edited edge metadata.May 13 2015, 4:31 AM

Macro bulbasaur:
Macro rubberstamp:

usr.sbin/pmcstat/pmcstat_log.c
719

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

Macro bikeshed:

rpaulo accepted this revision.May 13 2015, 4:31 AM
rpaulo edited edge metadata.
This revision is now accepted and ready to land.May 13 2015, 4:31 AM
stas closed this revision.May 13 2015, 7:15 PM
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.