Cf. the thread "recovering the load address for an
image" in the oprofile-list.
Oprofile stores samples as offsets from the point the
(user space) image is mapped in memory. Because it
(apparently) does not record the point from which it
calculates offsets, when returning results for
"opreport -d", it relies on the symbol table to figure
out a reusable and persistent VMA. (A good reusable
VMA is the one stored in the binary (e.g. ELF) header
structures and returned by objdump.) Besides the
problems mentioned in the oprofile-list thread
referenced above, this causes "opreport -d" to return
bogus VMAs for stripped executables.
For example, here is part of 'objdump --disassemble'
for /bin/bash on my system:
805a6b4: 55 push %ebp
805a6b5: 89 e5 mov %esp,%ebp
805a6b7: 83 ec 08 sub $0x8,%esp
Here is are the type of VMAs opreport produces:
00000000 372 0.0125 bash (no
00012a9c 1 0.2688
00012c0c 1 0.2688
00012f2c 1 0.2688
00012fcc 3 0.8065
It would be very nice to have a way to convert the
sample offsets into reusable VMAs *without* being
forced to use the symbol table (for reasons explained
in the oprofile-list thread).
E.g., is there a way to know the exact offset an image
will be loaded in memory? This would at least convert
offsets into offsets from the beginning of the image.
Log in to post a comment.