Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: John Levon <levon@mo...> - 2002-05-29 15:46:31
On Wed, May 29, 2002 at 04:24:17PM +0100, Jan Vroonhof wrote:
> 1. oprofpp -l seems to attribute the samples to the wrong function
> I have created a small C program to show the problem (doofoo.c) which
> is attached. Also attached is an "objdump -S" disassembly of the
> program to prove that the debugging info is there.
Using your binary and sample file, on current CVS, I get :
vma samples %-age symbol name linenr info
080482dc 0 0 _start (no location information)
08048300 0 0 Letext (no location information)
08048324 0 0 __do_global_dtors_aux (no location information)
0804836c 0 0 fini_dummy (no location information)
08048374 0 0 frame_dummy (no location information)
08048394 0 0 init_dummy (no location information)
08048430 0 0 __do_global_ctors_aux (no location information)
08048458 0 0 init_dummy (no location information)
08048460 0 0 _fini (no location information)
0804840c 11 0.0020458 main /tmp/dofoo.c:25
0804839c 229873 42.7521 foo /tmp/dofoo.c:5
080483d4 307804 57.2458 bar /tmp/dofoo.c:15
So either we've fixed a bug since 0.2-release, or it's a binutils
problem. I think it's a binutils problem, could you please try
oprofile CVS and confirm it's still broken ?
> This seems to be to the fact that it gets the adresses for foo/bar completely wrong.
This is very odd.
> /tmp> op_to_source -i ./dofoo
> Request for source file annotated with samples but no debug info available
Phil, can you remember when this happens ?
"A Mini Cooper ? I wouldn't be seen dead in one of those !"
- Mickey Finn
From: Jan Vroonhof <jan.vroonhof@in...> - 2002-05-29 16:13:58
John Levon <levon@...> writes:
> So either we've fixed a bug since 0.2-release, or it's a binutils
> problem. I think it's a binutils problem, could you please try
> oprofile CVS and confirm it's still broken ?
At the very least it is a binutils<-->oprofile interation problem:
Switching to CVS did not change anything.
Linking statically to an (old) libbfd.a of otherwise unknown provenance fixed the
To repeat the original buggy one is 184.108.40.206.1-4 from Debian.
P.S. oprofile is cool. Thanks a lot
From: John Levon <levon@mo...> - 2002-05-30 23:50:35
On Wed, May 29, 2002 at 05:13:38PM +0100, Jan Vroonhof wrote:
> To repeat the original buggy one is 220.127.116.11.1-4 from Debian.
Well, now I'm perplexed. I downloaded the tarball and patch from debian,
and built oprofpp against it :
moz pp 223 strings oprofpp | grep 2.9.
moz pp 224 ./oprofpp -f /home/moz/\}tmp\}dofoo#0 -i ~/dofoo -l
0804839c 229873 42.7521 foo
080483d4 307804 57.2458 bar
So I'm at a loss to explain the problem you were having, since you
said it happened with all three compilers producing the source file
"Do you mean to tell me that "The Prince" is not the set textbook for CS1072
Professional Issues ? What on earth do you learn in that course ?"
- David Lester