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

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

[guanglei at cn dot ibm dot com]

See:
http://sourceware.org/bugzilla/show_bug.cgi?id=2453#c8

I know that for x86, kprobe uses the address right after the function prologue,
and kretprobe uses the address of the very beginning of that function.

But should there be some differences with PowerPC since it's a register based
and will have a different method to find the address used by kprobe? Maybe we
can just let both kprobe & kretprobe to use the address given by
kallsyms_lookup_name(function) ?

Sorry if I am wrong with something.

-- 
           Summary: possible wrong function.entry address given by systemtap
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: guanglei at cn dot ibm dot com


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.

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

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-03-16 13:33 -------
In other words, something may be wrong with the prologue analysis heuristics in
systemtap on powerpc.

On IA64, src/tapsets.cxx sort of disables prologue searching in
query_func_info().  Would you mind trying the same trick for powerpc and see
whether it affects not just this problem but the rest of the test cases?


-- 


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.

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

[guanglei at cn dot ibm dot com]

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

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

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-03-21 14:30 -------
If there is a prologue defined by the ABI, and if the DWARF info does not
sufficiently describe its end, then systemtap (like gdb) will need to put its
breakpoints after the prologue.  Otherwise, accessing function parameters based
on DWARF data will not be possible.

-- 


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.

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

[guanglei at cn dot ibm dot com]

------- Additional Comments From guanglei at cn dot ibm dot com  2006-04-10 03:21 -------
Frank did some changes to the prologue heuristic code, pls refer to:
http://sources.redhat.com/ml/systemtap/2006-q2/msg00067.html

In our regular basis testing against LKET, we will keep an eye on this change,
and report any abnormal if it happens

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liangss at cn dot ibm dot
                   |                            |com


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.

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

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-04-26 14:51 -------
Can you check whether the fix from last week corrected your particular problem?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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.

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

[guanglei at cn dot ibm dot com]

------- Additional Comments From guanglei at cn dot ibm dot com  2006-04-27 02:38 -------
(In reply to comment #5)
> Can you check whether the fix from last week corrected your particular problem?

Pls see comment #13 of bug 2453
http://sourceware.org/bugzilla/show_bug.cgi?id=2453#c13

I also tried on 2.6.15.4 again with the latest code from CVS, it also works for
me :-) :

the file generead by -p3:
...
static struct kprobe dwarf_kprobe_0[1]= {
  {.addr= (void *) 0xc0000000001f015c}
};
...

objdump of kernel:
c0000000001f015c <.elv_dequeue_request>:
c0000000001f015c:       e8 04 00 00     ld      r0,0(r4)
c0000000001f0160:       7c 00 22 78     xor     r0,r0,r4
c0000000001f0164:       21 20 00 00     subfic  r9,r0,0
c0000000001f0168:       7c 09 01 14     adde    r0,r9,r0
c0000000001f016c:       0b 00 00 00     tdnei   r0,0
c0000000001f0170:       e9 24 00 00     ld      r9,0(r4)

stap -vvv output:
/home/root> stap a.stp -vvv
Created temporary directory "/tmp/stapxIXO09"
Searched '/usr/local/share/systemtap/tapset/2.6.15.4/ppc64/*.stp', match count 0
Searched '/usr/local/share/systemtap/tapset/2.6.15.4/*.stp', match count 0
Searched '/usr/local/share/systemtap/tapset/2.6.15/ppc64/*.stp', match count 0
Searched '/usr/local/share/systemtap/tapset/2.6.15/*.stp', match count 0
Searched '/usr/local/share/systemtap/tapset/2.6/ppc64/*.stp', match count 0
Searched '/usr/local/share/systemtap/tapset/2.6/*.stp', match count 0
Searched '/usr/local/share/systemtap/tapset/ppc64/*.stp', match count 1
Searched '/usr/local/share/systemtap/tapset/*.stp', match count 15
Pass 1: parsed user script and 16 library script(s) in 230usr/0sys/335real ms.
parsed 'elv_dequeue_request' -> func 'elv_dequeue_request'
pattern 'kernel' matches module 'kernel'
focused on module 'kernel' = [c000000000000000-c0000000007b66a8, bias 0]
pattern 'elv_dequeue_request' matches function 'elv_dequeue_request'
selected function elv_dequeue_request
prologue searching function 'elv_dequeue_request'
0xc0000000001f015c-0xc0000000001f01b4@block/elevator.c:513
checking line record 0xc0000000001f015c@include/linux/list.h:255
prologue found function 'elv_dequeue_request' (naked) = 0xc0000000001f015c
probe elv_dequeue_request@block/elevator.c:513 pc=0xc0000000001f015c
pattern 'kernel' matches module 'kernel'
Eliding unused function warn
Eliding unused function exit
Eliding unused function error
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 global(s) in
440usr/140sys/1071real ms.
Probe #0 locks nothing
Running grep " [tT] " /proc/kallsyms | sort -k 1,8 -s -o
/tmp/stapxIXO09/symbols.sorted
Pass 3: translated to C into "/tmp/stapxIXO09/stap_3582.c" in
140usr/100sys/261real ms.
Running make -C "/lib/modules/2.6.15.4/build" M="/tmp/stapxIXO09" modules V=1
make: Entering directory `/usr/src/linux-2.6.15.4'
mkdir -p /tmp/stapxIXO09/.tmp_versions
make -f scripts/Makefile.build obj=/tmp/stapxIXO09
  gcc -m64 -Wp,-MD,/tmp/stapxIXO09/.stap_3582.o.d  -nostdinc -isystem
/usr/lib/gcc/ppc64-redhat-linux/3.4.5/include -D__KERNEL__ -Iinclude  -include
include/linux/autoconf.h  -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -ffreestanding -Os     -fomit-frame-pointer -g
-msoft-float -pipe -mminimal-toc -mtraceback=none  -mcall-aixdesc -mtune=power4
-mno-altivec -funit-at-a-time -mstring -Wa,-maltivec
-Wdeclaration-after-statement  -Wno-unused 
-I"/usr/local/share/systemtap/runtime"   -DMODULE -DKBUILD_BASENAME=stap_3582
-DKBUILD_MODNAME=stap_3582 -c -o /tmp/stapxIXO09/.tmp_stap_3582.o
/tmp/stapxIXO09/stap_3582.c
  Building modules, stage 2.
make -rR -f /usr/src/linux-2.6.15.4/scripts/Makefile.modpost
  scripts/mod/modpost -m -a -i /usr/src/linux-2.6.15.4/Module.symvers vmlinux
/tmp/stapxIXO09/stap_3582.o
  gcc -m64 -Wp,-MD,/tmp/stapxIXO09/.stap_3582.mod.o.d  -nostdinc -isystem
/usr/lib/gcc/ppc64-redhat-linux/3.4.5/include -D__KERNEL__ -Iinclude  -include
include/linux/autoconf.h  -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -ffreestanding -Os     -fomit-frame-pointer -g
-msoft-float -pipe -mminimal-toc -mtraceback=none  -mcall-aixdesc -mtune=power4
-mno-altivec -funit-at-a-time -mstring -Wa,-maltivec
-Wdeclaration-after-statement     -DKBUILD_BASENAME=stap_3582
-DKBUILD_MODNAME=stap_3582 -DMODULE -c -o /tmp/stapxIXO09/stap_3582.mod.o
/tmp/stapxIXO09/stap_3582.mod.c
  ld -m elf64ppc  -r -o /tmp/stapxIXO09/stap_3582.ko /tmp/stapxIXO09/stap_3582.o
/tmp/stapxIXO09/stap_3582.mod.o
make: Leaving directory `/usr/src/linux-2.6.15.4'
Pass 4: compiled C into "stap_3582.ko" in 3640usr/310sys/8361real ms.
Pass 5: starting run.
Running sudo /usr/local/libexec/systemtap/stpd -r -u root -d 3582
/tmp/stapxIXO09/stap_3582.ko
here
here
here

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED


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.