public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* do_mmap fails to work on RHEL5.1GA
@ 2007-12-18  0:58 baiwd
  2007-12-18  3:29 ` Frank Ch. Eigler
  0 siblings, 1 reply; 4+ messages in thread
From: baiwd @ 2007-12-18  0:58 UTC (permalink / raw)
  To: systemtap

Hello:
     When I test with the newest stp on RHEL5.1GA, I  found that probe 
for do_mmap in memory.stp
cannot work correctly. It reported:
Pass 1: parsed user script and 38 library script(s) in 
306usr/4sys/325real ms.
Pass 2: analyzed script: 14 probe(s), 0 function(s), 0 embed(s), 0 
global(s) in 1076usr/97sys/1172real ms.
Pass 3: translated to C into 
"/tmp/stapLlRNuv/stap_5a545779c7b8d4c8da640eed3f8c78f8_2314.c" in 
1usr/0sys/1real ms.
Pass 4: compiled C into "stap_5a545779c7b8d4c8da640eed3f8c78f8_2314.ko" 
in 4715usr/245sys/4710real ms.
Pass 5: starting run.
ERROR: probe kernel.function("do_mmap@include/linux/mm.h:1001") 
registration error (rc -22)
      By looking through the elf file of linux kernel debug and the 
source codes, I think do_mmap and do_mmap2
are inlined functions, and they maybe inlined in optimization. But I 
find that do_mmap and do_mmap2 in all the
versions use do_mmap_pgoff which is not inlined and use almost the same 
arguments as do_mmap and do_mmap2.
So I wondered whether memory.stp can be changed as following:

--- memory.stp.old 2007-12-12 14:14:46.000000000 +0900
+++ memory.stp 2007-12-12 14:40:52.000000000 +0900
@@ -112,7 +112,7 @@ probe vm.write_shared_copy = kernel.func
* address - the requested address
* length - the length of the memory segment
*/
-probe vm.mmap = kernel.function("do_mmap"), kernel.function("do_mmap2")? {
+probe vm.mmap = kernel.function("do_mmap_pgoff") {
address = $addr
length = $len
}


 From Bai Weidong <baiwd@cn.fujitsu.com>
Best Regards

^ permalink raw reply	[flat|nested] 4+ messages in thread
* do_mmap fails to work on RHEL5.1GA
@ 2007-12-18  0:53 baiwd
  0 siblings, 0 replies; 4+ messages in thread
From: baiwd @ 2007-12-18  0:53 UTC (permalink / raw)
  To: systemtap

Hello:
    When I test with the newest stp on RHEL5.1GA, I  found that probe 
for do_mmap in memory.stp
cannot work correctly. It reported:
Pass 1: parsed user script and 38 library script(s) in 
306usr/4sys/325real ms.
Pass 2: analyzed script: 14 probe(s), 0 function(s), 0 embed(s), 0 
global(s) in 1076usr/97sys/1172real ms.
Pass 3: translated to C into 
"/tmp/stapLlRNuv/stap_5a545779c7b8d4c8da640eed3f8c78f8_2314.c" in 
1usr/0sys/1real ms.
Pass 4: compiled C into "stap_5a545779c7b8d4c8da640eed3f8c78f8_2314.ko" 
in 4715usr/245sys/4710real ms.
Pass 5: starting run.
ERROR: probe kernel.function("do_mmap@include/linux/mm.h:1001") 
registration error (rc -22)
     By looking through the elf file of linux kernel debug and the 
source codes, I think do_mmap and do_mmap2
are inlined functions, and they maybe inlined in optimization. But I 
find that do_mmap and do_mmap2 in all the
versions use do_mmap_pgoff which is not inlined and use almost the same 
arguments as do_mmap and do_mmap2.
So I wondered whether memory.stp can be changed as following:

--- memory.stp.old 2007-12-12 14:14:46.000000000 +0900
+++ memory.stp 2007-12-12 14:40:52.000000000 +0900
@@ -112,7 +112,7 @@ probe vm.write_shared_copy = kernel.func
* address - the requested address
* length - the length of the memory segment
*/
-probe vm.mmap = kernel.function("do_mmap"), kernel.function("do_mmap2")? {
+probe vm.mmap = kernel.function("do_mmap_pgoff") {
address = $addr
length = $len
}


 From Bai Weidong <baiwd@cn.fujitsu.com>
Best Regards

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-12-18  5:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-18  0:58 do_mmap fails to work on RHEL5.1GA baiwd
2007-12-18  3:29 ` Frank Ch. Eigler
2007-12-18  5:47   ` baiwd
  -- strict thread matches above, loose matches on Subject: below --
2007-12-18  0:53 baiwd

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).