[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oprofile-list
Subject:    [ oprofile-Bugs-1170794 ] Errror in VMAs from "opreport -d"
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2005-03-26 0:20:50
Message-ID: E1DEz2o-0004uz-L1 () sc8-sf-web4 ! sourceforge ! net
[Download RAW message or body]

Bugs item #1170794, was opened at 2005-03-25 22:58
Message generated for change (Comment added) made by movement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1170794&group_id=16191

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nathan Tallent (nathantallent)
Assigned to: Nobody/Anonymous (nobody)
Summary: Errror in VMAs from "opreport -d"

Initial Comment:
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.



----------------------------------------------------------------------

>Comment By: John Levon (movement)
Date: 2005-03-26 00:20

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=1170794&group_id=16191


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
[prev in list] [next in list] [prev in thread] [next in thread]