This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/2465] possible wrong function.entry address given by systemtap
- From: "guanglei at cn dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 21 Mar 2006 09:38:01 -0000
- Subject: [Bug translator/2465] possible wrong function.entry address given by systemtap
- References: <20060316093856.2465.guanglei@cn.ibm.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From guanglei at cn dot ibm dot com 2006-03-21 09:38 -------
I tried the following patch:
-bash-3.00# diff -uprN ~/tapsets.cxx.orig ./tapsets.cxx
--- /home/root/tapsets.cxx.orig 2006-03-21 08:32:40.000000000 -0500
+++ ./tapsets.cxx 2006-03-21 03:45:29.000000000 -0500
@@ -2137,7 +2137,7 @@ query_func_info (Dwarf_Addr entrypc,
}
else
{
-#ifdef __ia64__
+#if defined(__ia64__) || defined(__powerpc__)
// In IA64 platform function probe point is set at its
// entry point rather than prologue end pointer
query_statement (fi.name, fi.decl_file, fi.decl_line,
-bash-3.00#
It worked well. "make check" and "runtest --tool=systemtap" show the same result
as the original version. And my own testcases also showed that it is ok.
But ppc64 also have the concept of function prologue which will establishe a
stack frame, and if necessary, and may save any nonvolatile registers.
But I can't see what the problem is if kprobe is put at the very beginning of
the function entry point instead of the end of function prologue. Anyone can
tell the requirement of putting kprobes at end of function prologue? Someone
else tell me that it depends on how gcc generate the dwarf info.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=2465
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.