#128 Errror in VMAs from "opreport -d"

closed-invalid
nobody
None
5
2005-03-26
2005-03-25
No

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:

0805a6b4 <_init>:
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
symbols)
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.

Discussion

  • John Levon

    John Levon - 2005-03-26

    Logged In: YES
    user_id=53034

    Regarding the output you show: this is no error, in this
    case, the values shown are raw offsets from the start of the
    file.

    opreport -d is indeed symbol-based, and there are no plans
    at current to change this. It would be possible, in the case
    where there's no symbols, to introduce synthetic symbols for
    each section, and report data like that, but it's of little
    use as far as I can see.

    As the "bug" reported here is expected and correct
    behaviour, I'm closing this. I've added a paragraph to the
    documentation to make the behaviour clear.

    Please continue any discussion on the mailing list.

     
  • John Levon

    John Levon - 2005-03-26
    • status: open --> closed-invalid
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks