[oprof-cvs] CVS: oprofile ChangeLog, 1.1749.2.55, 1.1749.2.56 TODO.jit, 1.1.2.14, 1.1.2.15

[Philippe E. <ph...@us...>]

Update of /cvsroot/oprofile/oprofile
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv25546

Modified Files:
      Tag: JIT_SUPPORT
	ChangeLog TODO.jit 
Log Message:
change again the way anon samples are handled, use relative samples in samples files but rather to try to do the fixup in op_bfd, do it only in profile.cpp

Index: ChangeLog
===================================================================
RCS file: /cvsroot/oprofile/oprofile/ChangeLog,v
retrieving revision 1.1749.2.55
retrieving revision 1.1749.2.56
diff -u -p -d -r1.1749.2.55 -r1.1749.2.56
--- ChangeLog	14 Dec 2007 22:46:29 -0000	1.1749.2.55
+++ ChangeLog	17 Dec 2007 16:47:14 -0000	1.1749.2.56
@@ -1,3 +1,21 @@
+2007-12-17  Philippe Elie  <ph...@wa...>
+
+	change again the way anon samples are handled, use relative samples
+	in samples files but rather to try to do the fixup in op_bfd, do it
+	only in profile.cpp, this is simpler and more reliable. I needed
+	again to add a hack in op_bfd.cpp because we need to know if a bfd
+	object is a anon file by looking the file extension, there is probably
+	a better way todo that.
+	* libpp/profile.cpp:
+	* libutil++/op_bfd.cpp:
+	* libutil++/op_bfd.h:
+	* libpp/callgraph_container.cpp:
+	* libpp/profile_container.cpp:
+	* libpp/profile_container.h:
+	* libutil++/bfd_support.cpp:
+	* libutil++/bfd_support.h:
+	* pp/opgprof.cpp:
+
 2007-12-14  Maynard Johnson  <may...@us...>
 
 	* libutil/op_file.c:

Index: TODO.jit
===================================================================
RCS file: /cvsroot/oprofile/oprofile/Attic/TODO.jit,v
retrieving revision 1.1.2.14
retrieving revision 1.1.2.15
diff -u -p -d -r1.1.2.14 -r1.1.2.15
--- TODO.jit	14 Dec 2007 22:55:27 -0000	1.1.2.14
+++ TODO.jit	17 Dec 2007 16:47:14 -0000	1.1.2.15
@@ -81,20 +81,3 @@ Massi added than for mono, code on the s
 no byte code, code is always compiled to native machine code, this mean than
 for mono at least we can do callgraph if we can fix this samples filename
 problem.
-
--------
-
-<gisle> Hm, I'm getting a strange result with a very simple program: A sequence of samples show's up in two different code regions!
-<gisle> This is using opannotate -a
-<gisle> Example:17509 26.1774 : 400018a81b0:   mr      r30,r5
-<gisle> And then: 17509 26.1774 : 40001e231b0:   addi    r3,r29,-8
-<gisle> The second one is correct, the first is wrong
-<gisle> Interestingly, they both end in the same three digits
-<gisle> it's opannotate -a on a .jo file
-<gisle> (generated from an anonoymous region)
-<gisle> Something similar happens in opreport -la 
-<gisle> samples  cum. samples  %        cum. %     image name               app name                 symbol name
-<gisle> 33427    8396533        0.3945  99.0988    13628.jo                 dynamite                 GB_0xbefed15d_BB_0xbefed17c_0x917c_0xbefed188_0x9188_/lib/ld-linux.so.2
-<gisle> 33410    8429943        0.3943  99.4931    13628.jo                 dynamite                 GB_0x804882f_BB_0x804882f_0x82f_0x804884a_0x84a_0x804882_loop.exe
-<gisle> The first line is wrong (well I suspect there should be 33410 less samples there)
-<gisle> Any idea how this can happen? Looks like samples are being mapped twice...