pmcstat: fix PPC kernel symbol resolution

[luporl]

Summary

PowerPC kernel is of DYN type and it has a base address where it is initially loaded, before being relocated.
As the start address passed to pmcstat_image_link() is where the kernel was relocated to, but the symbols always use the original base address, we need to subtract it to get the correct offset.

[bdragon]

Makes sense to me. Is there a good way to test this?

Additionally, I believe this would also be relevant to ppc32, perhaps use the __powerpc__ ifdef instead.

[jhibbits]

lib/libpmcstat/libpmcstat_image.c

180

This probably affects all powerpc platforms, not just powerpc64. They're all ET_DYN, and I know on Book-E 32-bit does get relocated.

198

Same down here.

[luporl]

In D26114#580412, @bdragon wrote:

Makes sense to me. Is there a good way to test this?

Additionally, I believe this would also be relevant to ppc32, perhaps use the __powerpc__ ifdef instead.

I've tested it on Talos with D26110, D26111, D26112 and D26113, to collect samples and produce a callgraph:

cd /tmp
dd if=/dev/zero of=ddtmp bs=1m count=2048 &
pmcstat -O sample.out -S INSTR_COMPLETED -l 5
pmcstat -R sample.out -G sample.graph

The dd is to force a predictable kernel load, to know what functions to expect in the output.
Then sample.graph should have symbols resolved correctly and shows tmpfs_write and uiomove_object among functions that spent most time.
(I have /tmp mounted as tmpfs)

You could probably test this on a G5 too, but you'll need D26111 if you start getting panics and D26112 to avoid addresses being truncated to 32-bit.

I can change the #ifdef to __powerpc__, but it would be nice if someone could test it on a PPC32 machine to make sure it works.

[luporl]

Address jhibbits' comments