This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/2465] possible wrong function.entry address given by systemtap


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]