* semantic error
@ 2013-01-21 14:36 Mehul Choube
2013-01-21 15:06 ` Frank Ch. Eigler
0 siblings, 1 reply; 11+ messages in thread
From: Mehul Choube @ 2013-01-21 14:36 UTC (permalink / raw)
To: systemtap
Hi,
I am trying to build and run systemtap 2.0 on SLES 11 SP1. The build was successful but 'stap' gives semantic error while running though SYSTEMTAP_RUNTIME and SYSTEMTAP_TAPSET is set. Please check http://pastebin.com/iAdNsg9C
Everything runs fine with default stap:
sles11sp1:~/systemtap-2.0-11151/bin # /usr/bin/stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'
Pass 1: parsed user script and 59 library script(s) in 100usr/0sys/104real ms.
Pass 2: analyzed script: 1 probe(s), 11 function(s), 2 embed(s), 1 global(s) in 270usr/260sys/2587real ms.
Pass 3: translated to C into "/tmp/stapo8i6Ve/stap_a661581e288025046b111a4956a536fa_4978.c" in 210usr/130sys/428real ms.
Pass 4: compiled C into "stap_a661581e288025046b111a4956a536fa_4978.ko" in 1380usr/240sys/9987real ms.
Pass 5: starting run.
read performed
Pass 5: run completed in 10usr/40sys/304real ms.
Please advice what wrong am doing here.
Thanks,
Mehul
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: semantic error
2013-01-21 14:36 semantic error Mehul Choube
@ 2013-01-21 15:06 ` Frank Ch. Eigler
2013-01-21 15:43 ` Mehul Choube
0 siblings, 1 reply; 11+ messages in thread
From: Frank Ch. Eigler @ 2013-01-21 15:06 UTC (permalink / raw)
To: Mehul Choube; +Cc: systemtap
Mehul Choube <Mehul_Choube@symantec.com> writes:
> [...]
> I am trying to build and run systemtap 2.0 on SLES 11 SP1. The build
> was successful but 'stap' gives semantic error while running though
> SYSTEMTAP_RUNTIME and SYSTEMTAP_TAPSET is set. Please check
> http://pastebin.com/iAdNsg9C
This sounds like a conflict between your personal stap build and the
system one. If http://sourceware.org/PR12443 was responsible, try
% unset XDG_DATA_DIRS
% /root/.../stap ...
- FChE
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: semantic error
2013-01-21 15:06 ` Frank Ch. Eigler
@ 2013-01-21 15:43 ` Mehul Choube
2013-01-21 16:23 ` Frank Ch. Eigler
0 siblings, 1 reply; 11+ messages in thread
From: Mehul Choube @ 2013-01-21 15:43 UTC (permalink / raw)
To: systemtap
Now the command doesn't return at all:
sles11sp1:~/systemtap-2.0-11151/bin # time SYSTEMTAP_RUNTIME=/root/systemtap-2.0-11151/share/systemtap/runtime SYSTEMTAP_TAPSET=/root/systemtap-2.0-11151/share/systemtap/tapset ./stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'
Pass 1: parsed user script and 89 library script(s) using 40480virt/20804res/1928shr/19460data kb, in 140usr/10sys/145real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 3 embed(s), 0 global(s) using 184632virt/93828res/6092shr/86576data kb, in 980usr/70sys/2963real ms.
Pass 3: translated to C into "/tmp/stapZOEqQy/stap_e3c44decc9b9ce95ac6db0284b62d776_1713_src.c" using 176664virt/90616res/4780shr/86576data kb, in 0usr/0sys/5real ms.
Pass 4: compiled C into "stap_e3c44decc9b9ce95ac6db0284b62d776_1713.ko" in 3980usr/600sys/33562real ms.
Pass 5: starting run.
Write failed: Broken pipe
mchoube@udesk:~$
Thanks,
Mehul
-----Original Message-----
From: Frank Ch. Eigler [mailto:fche@redhat.com]
Sent: Monday, January 21, 2013 8:37 PM
To: Mehul Choube
Cc: systemtap@sourceware.org
Subject: Re: semantic error
Mehul Choube <Mehul_Choube@symantec.com> writes:
> [...]
> I am trying to build and run systemtap 2.0 on SLES 11 SP1. The build
> was successful but 'stap' gives semantic error while running though
> SYSTEMTAP_RUNTIME and SYSTEMTAP_TAPSET is set. Please check
> http://pastebin.com/iAdNsg9C
This sounds like a conflict between your personal stap build and the
system one. If http://sourceware.org/PR12443 was responsible, try
% unset XDG_DATA_DIRS
% /root/.../stap ...
- FChE
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: semantic error
2013-01-21 15:43 ` Mehul Choube
@ 2013-01-21 16:23 ` Frank Ch. Eigler
2013-01-22 9:35 ` Mehul Choube
0 siblings, 1 reply; 11+ messages in thread
From: Frank Ch. Eigler @ 2013-01-21 16:23 UTC (permalink / raw)
To: Mehul Choube; +Cc: systemtap
Mehul Choube <Mehul_Choube@symantec.com> writes:
> Now the command doesn't return at all:
> [...]
> sles11sp1:~/systemtap-2.0-11151/bin # time SYSTEMTAP_RUNTIME=/root/systemtap-2.0-11151/share/systemtap/runtime SYSTEMTAP_TAPSET=/root/systemtap-2.0-11151/share/systemtap/tapset ./stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'
For a hand-built stap, you should not require the
SYSTEMTAP_{RUNTIME,TAPSET} env vars at all, since those are compiled
into your ./stap binary.
> [...]
> Pass 4: compiled C into "stap_e3c44decc9b9ce95ac6db0284b62d776_1713.ko" in 3980usr/600sys/33562real ms.
> Pass 5: starting run.
> Write failed: Broken pipe
> mchoube@udesk:~$
Did you do a make-install for stap to find the staprun/stapio programs?
Add a "--vp 00004" to the stap options to gather more data. But the
initial $XDG_DATA_DIRS conflict is gone.
- FChE
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: semantic error
2013-01-21 16:23 ` Frank Ch. Eigler
@ 2013-01-22 9:35 ` Mehul Choube
0 siblings, 0 replies; 11+ messages in thread
From: Mehul Choube @ 2013-01-22 9:35 UTC (permalink / raw)
To: systemtap
Yes I did ran "make install" after the build.
The output using "--vp 00004" is: http://pastebin.com/zDGPhMdu
Also, kernel crashed:
sles11sp1:/var/crash/2013-01-22-14:36 # ls -lrth
total 3.1G
-rw------- 1 root root 3.0G 2013-01-22 14:40 vmcore
-rw-r--r-- 1 root root 1.6M 2013-01-22 14:40 System.map-2.6.32.12-0.7-default
-rw-r--r-- 1 root root 187 2013-01-22 14:40 README.txt
-rw-r--r-- 1 root root 3.6M 2013-01-22 14:40 vmlinux-2.6.32.12-0.7-default.gz
-rw-r--r-- 1 root root 68M 2013-01-22 14:41 vmlinux-2.6.32.12-0.7-default.debug
Thanks,
Mehul
-----Original Message-----
From: Frank Ch. Eigler [mailto:fche@redhat.com]
Sent: Monday, January 21, 2013 9:53 PM
To: Mehul Choube
Cc: systemtap@sourceware.org
Subject: Re: semantic error
Mehul Choube <Mehul_Choube@symantec.com> writes:
> Now the command doesn't return at all:
> [...]
> sles11sp1:~/systemtap-2.0-11151/bin # time SYSTEMTAP_RUNTIME=/root/systemtap-2.0-11151/share/systemtap/runtime SYSTEMTAP_TAPSET=/root/systemtap-2.0-11151/share/systemtap/tapset ./stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'
For a hand-built stap, you should not require the
SYSTEMTAP_{RUNTIME,TAPSET} env vars at all, since those are compiled
into your ./stap binary.
> [...]
> Pass 4: compiled C into "stap_e3c44decc9b9ce95ac6db0284b62d776_1713.ko" in 3980usr/600sys/33562real ms.
> Pass 5: starting run.
> Write failed: Broken pipe
> mchoube@udesk:~$
Did you do a make-install for stap to find the staprun/stapio programs?
Add a "--vp 00004" to the stap options to gather more data. But the
initial $XDG_DATA_DIRS conflict is gone.
- FChE
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: semantic error
2012-09-26 19:35 ` domenico.dileo
@ 2012-09-27 21:01 ` domenico.dileo
0 siblings, 0 replies; 11+ messages in thread
From: domenico.dileo @ 2012-09-27 21:01 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: systemtap
Dear Frank,
since that we needed to log all the data we could gathered,
we tried to solve the problem by redirecting the data
to the serial port.
It seems to work, at least we don't exceed the threshold
Thank you for all your support,
Domenico
Quoting domenico.dileo@unina.it:
> Dear Frank hereafter the output of the command you asked to me:
>
> stap-report
> == stap -V ==
> == which stap ==
> /usr/local/bin/stap
> == locate --regex '/stap(run)?$' | xargs ls -ald ==
> drwxr-xr-x 2 root root 4096 Sep 26 20:13 .
> == printenv | egrep '^PATH=|^LD_LIBRARY_PATH=|^SYSTEMTAP_.*=|^XDG_DATA.*=' ==
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.2:/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/i686-pc-linux-gnu/gnat-gcc-bin/4.2:/usr/libexec/gnat-gcc/i686-pc-linux-gnu/4.2
> XDG_DATA_DIRS=/usr/share:/usr/kde/3.5/share:/usr/local/share
> == stap -vv -p4 -e 'probe begin {exit()}' ==
> /root/.systemtap/cache/a3/stap_a3fbb36bd163c0248871a038b3d3d3bd_627.ko
> == gcc -v ==
> == uname -a ==
> Linux FNML-Console 2.6.24-FNM_v2.1 #3 SMP PREEMPT RT Fri Aug 3
> 13:41:21 CEST 2012 i686 Genuine Intel(R) CPU U4100 @ 1.30GHz
> GenuineIntel GNU/Linux
> == dmesg | egrep 'stap|systemtap' | tail -n 10 ==
> == cat /proc/cpuinfo | egrep 'processor|vendor_id|model name' ==
> processor : 0
> vendor_id : GenuineIntel
> model name : Genuine Intel(R) CPU U4100 @ 1.30GHz
> == rpm -qa --qf '%{name}-%{version} %{release}.%{arch}\n' | egrep
> 'systemtap|elfutils|kernel|gcc' | sort ==
> == egrep 'PROBE|TRACE|MARKER|_DEBUG_'
> /lib/modules/2.6.24-FNM_v2.1/build/.config | grep -v not.set | sort
> | fmt -w 80 ==
> CONFIG_AIC79XX_DEBUG_MASK=0 CONFIG_AIC7XXX_DEBUG_ENABLE=y
> CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_CONTEXT_SWITCH_TRACER=y
> CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_FS=y CONFIG_DEBUG_HIGHMEM=y
> CONFIG_DEBUG_INFO=y CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_KOBJECT=y
> CONFIG_DEBUG_LIST=y CONFIG_DEBUG_PAGEALLOC=y CONFIG_DEBUG_PREEMPT=y
> CONFIG_DEBUG_RODATA=y CONFIG_DEBUG_SG=y CONFIG_DEBUG_SHIRQ=y
> CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_SLAB_LEAK=y CONFIG_DEBUG_SPINLOCK=y
> CONFIG_DEBUG_STACK_USAGE=y CONFIG_DEBUG_VM=y CONFIG_EVENT_TRACER=y
> CONFIG_FAULT_INJECTION_DEBUG_FS=y CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y
> CONFIG_GENERIC_IRQ_PROBE=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE=y
> CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_KPROBES=y CONFIG_MARKERS=y
> CONFIG_PCMCIA_PROBE=y CONFIG_SCHED_TRACER=y CONFIG_SCSI_IPR_TRACE=y
> CONFIG_STACKTRACE=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_TRACER_MAX_TRACE=y
> CONFIG_TRACE_IRQFLAGS_SUPPORT=y
> == find /debugfs /proc /sys /dev -name '*kprobes*' 2>/dev/null |
> xargs grep . ==
>
> *********************************************************************
> cat /proc/kallsyms | grep setup_fail_slab
> nm /lib/modules/2.6.24-FNM_v2.1/build/vmlinux | grep setup_fail_slab
> give no output
>
> *********************************************************************
> readelf,,,
> There are 49 section headers, starting at offset 0x3a6e260:
>
> Section Headers:
> [Nr] Name Type Addr Off Size ES
> Flg Lk Inf Al
> [ 0] NULL 00000000 000000 000000 00
> 0 0 0
> [ 1] .text.head PROGBITS c0100000 001000 00037a 00
> AX 0 0 4
> [ 2] .text PROGBITS c0101000 002000 3f635a 00
> AX 0 0 4096
> [ 3] __ex_table PROGBITS c04f7360 3f8360 000e80 00
> A 0 0 8
> [ 4] .notes NOTE c04f81e0 3f91e0 000024 00
> AX 0 0 4
> [ 5] __bug_table PROGBITS c04f8208 3f9208 006cc0 00
> A 0 0 1
> [ 6] .rodata PROGBITS c04ff000 400000 140665 00
> A 0 0 128
> [ 7] .pci_fixup PROGBITS c063f668 540668 0008c0 00
> A 0 0 4
> [ 8] __ksymtab PROGBITS c063ff28 540f28 005ef8 00
> A 0 0 4
> [ 9] __ksymtab_gpl PROGBITS c0645e20 546e20 001f18 00
> A 0 0 4
> [10] __ksymtab_unused_ PROGBITS c0647d38 548d38 000010 00
> A 0 0 4
> [11] __ksymtab_gpl_fut PROGBITS c0647d48 548d48 000018 00
> A 0 0 4
> [12] __kcrctab PROGBITS c0647d60 548d60 002f7c 00
> A 0 0 4
> [13] __kcrctab_gpl PROGBITS c064acdc 54bcdc 000f8c 00
> A 0 0 4
> [14] __kcrctab_unused_ PROGBITS c064bc68 54cc68 000008 00
> A 0 0 4
> [15] __kcrctab_gpl_fut PROGBITS c064bc70 54cc70 00000c 00
> A 0 0 4
> [16] __ksymtab_strings PROGBITS c064bc80 54cc80 011c53 00
> A 0 0 32
> [17] __param PROGBITS c065d8d4 55e8d4 000ba4 00
> A 0 0 4
> [18] .data PROGBITS c065f000 560000 03de08 00
> WA 0 0 128
> [19] .data_nosave PROGBITS c069d000 59e000 001000 00
> WA 0 0 4096
> [20] .data.page_aligne PROGBITS c069e000 59f000 000800 00
> WA 0 0 32
> [21] .data.cacheline_a PROGBITS c069e800 59f800 0163ac 00
> WA 0 0 128
> [22] .data.read_mostly PROGBITS c06b4c00 5b5c00 002494 00
> WA 0 0 128
> [23] .data.init_task PROGBITS c06b8000 5b9000 001000 00
> WA 0 0 32
> [24] .smp_locks PROGBITS c06b9000 5ba000 003f94 00
> A 0 0 4
> [25] .init.text PROGBITS c06bd000 5be000 02aea8 00
> AX 0 0 16
> [26] .init.data PROGBITS c06e7ec0 5e8ec0 020172 00
> WA 0 0 32
> [27] .init.setup PROGBITS c0708040 609040 0006e4 00
> WA 0 0 4
> [28] .initcall.init PROGBITS c0708724 609724 0004dc 00
> WA 0 0 4
> [29] .con_initcall.ini PROGBITS c0708c00 609c00 000008 00
> WA 0 0 4
> [30] .altinstructions PROGBITS c0708c08 609c08 00bcf3 00
> A 0 0 4
> [31] .altinstr_replace PROGBITS c07148fb 6158fb 003011 00
> AX 0 0 1
> [32] .exit.text PROGBITS c0717910 618910 001902 00
> AX 0 0 16
> [33] .init.ramfs PROGBITS c071a000 61b000 000084 00
> A 0 0 1
> [34] .data.percpu PROGBITS c071b000 61c000 00663c 00
> WA 0 0 4096
> [35] .bss NOBITS c0722000 62263c 09b000 00
> WA 0 0 4096
> [36] .comment PROGBITS 00000000 62263c 00af4e 00
> 0 0 1
> [37] .debug_aranges PROGBITS 00000000 62d590 00bad8 00
> 0 0 8
> [38] .debug_pubnames PROGBITS 00000000 639068 04083b 00
> 0 0 1
> [39] .debug_info PROGBITS 00000000 6798a3 293841c 00
> 0 0 1
> [40] .debug_abbrev PROGBITS 00000000 2fb1cbf 1400b2 00
> 0 0 1
> [41] .debug_line PROGBITS 00000000 30f1d71 2bb041 00
> 0 0 1
> [42] .debug_frame PROGBITS 00000000 33acdb4 08607c 00
> 0 0 4
> [43] .debug_str PROGBITS 00000000 3432e30 1224e0 01
> MS 0 0 1
> [44] .debug_loc PROGBITS 00000000 3555310 417d3f 00
> 0 0 1
> [45] .debug_ranges PROGBITS 00000000 396d050 100fa0 00
> 0 0 8
> [46] .shstrtab STRTAB 00000000 3a6dff0 00026d 00
> 0 0 1
> [47] .symtab SYMTAB 00000000 3a6ea08 0ac3d0 10
> 48 30206 4
> [48] .strtab STRTAB 00000000 3b1add8 0e0251 00
> 0 0 1
> Key to Flags:
> W (write), A (alloc), X (execute), M (merge), S (strings)
> I (info), L (link order), G (group), x (unknown)
> O (extra OS processing required) o (OS specific), p (processor specific)
> *******************************************************************************
>
> CONFIG_DEBUG_INFO=y (in /boot/config)
> ******************************************************************************
>
> With kprobe.function("setup_fail_slab") the semantic error persists.
>
> Thank you.
>
>
> Quoting "Frank Ch. Eigler" <fche@redhat.com>:
>
>> Hi -
>>
>>> parse 'setup_fail_slab@mm/slab.c', func 'setup_fail_slab', file 'mm/slab.c'
>>> focused on module 'kernel' = [0x0xc0100000, -0x0xc07bd000, bias 0x0
>>> file /lib/modules/2.6.24-FNM_v2.1/build/vmlinux ELF machine i?86|
>>> (code 3)
>>> [...]
>>> semantic error: no match while resolving probe point
>>> kernel.function("setup_fail_slab@mm/slab.c").call
>>> parse 'setup_fail_slab@mm/slab.c', func 'setup_fail_slab', file 'mm/slab.c'
>>> [...]
>>
>> Can you run
>> stap-report
>> cat /proc/kallsyms | grep setup_fail_slab
>> nm /lib/modules/2.6.24-FNM_v2.1/build/vmlinux | grep setup_fail_slab
>> readelf -S /lib/modules/2.6.24-FNM_v2.1/build/vmlinux
>> Can you try kprobe.function("setup_fail_slab") instead of kernel.function()?
>> (I'm wondering if you're lacking CONFIG_DEBUG_INFO.)
>>
>> - FChE
>>
>>
>
>
>
> Domenico Di Leo, PhD student, Universit? degli Studi di Napoli Federico II
> Ph: +39 081 676770
> Fax: +39 081 676574
> Web: http://wpage.unina.it/domenico.dileo
>
>
>
Domenico Di Leo, PhD student, Universit? degli Studi di Napoli Federico II
Ph: +39 081 676770
Fax: +39 081 676574
Web: http://wpage.unina.it/domenico.dileo
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: semantic error
2012-09-26 16:09 ` Frank Ch. Eigler
@ 2012-09-26 19:35 ` domenico.dileo
2012-09-27 21:01 ` domenico.dileo
0 siblings, 1 reply; 11+ messages in thread
From: domenico.dileo @ 2012-09-26 19:35 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: systemtap
Dear Frank hereafter the output of the command you asked to me:
stap-report
== stap -V ==
== which stap ==
/usr/local/bin/stap
== locate --regex '/stap(run)?$' | xargs ls -ald ==
drwxr-xr-x 2 root root 4096 Sep 26 20:13 .
== printenv | egrep '^PATH=|^LD_LIBRARY_PATH=|^SYSTEMTAP_.*=|^XDG_DATA.*=' ==
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.2:/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/i686-pc-linux-gnu/gnat-gcc-bin/4.2:/usr/libexec/gnat-gcc/i686-pc-linux-gnu/4.2
XDG_DATA_DIRS=/usr/share:/usr/kde/3.5/share:/usr/local/share
== stap -vv -p4 -e 'probe begin {exit()}' ==
/root/.systemtap/cache/a3/stap_a3fbb36bd163c0248871a038b3d3d3bd_627.ko
== gcc -v ==
== uname -a ==
Linux FNML-Console 2.6.24-FNM_v2.1 #3 SMP PREEMPT RT Fri Aug 3
13:41:21 CEST 2012 i686 Genuine Intel(R) CPU U4100 @ 1.30GHz
GenuineIntel GNU/Linux
== dmesg | egrep 'stap|systemtap' | tail -n 10 ==
== cat /proc/cpuinfo | egrep 'processor|vendor_id|model name' ==
processor : 0
vendor_id : GenuineIntel
model name : Genuine Intel(R) CPU U4100 @ 1.30GHz
== rpm -qa --qf '%{name}-%{version} %{release}.%{arch}\n' | egrep
'systemtap|elfutils|kernel|gcc' | sort ==
== egrep 'PROBE|TRACE|MARKER|_DEBUG_'
/lib/modules/2.6.24-FNM_v2.1/build/.config | grep -v not.set | sort |
fmt -w 80 ==
CONFIG_AIC79XX_DEBUG_MASK=0 CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_FS=y CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_KOBJECT=y
CONFIG_DEBUG_LIST=y CONFIG_DEBUG_PAGEALLOC=y CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_RODATA=y CONFIG_DEBUG_SG=y CONFIG_DEBUG_SHIRQ=y
CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_SLAB_LEAK=y CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACK_USAGE=y CONFIG_DEBUG_VM=y CONFIG_EVENT_TRACER=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y
CONFIG_GENERIC_IRQ_PROBE=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_KPROBES=y CONFIG_MARKERS=y
CONFIG_PCMCIA_PROBE=y CONFIG_SCHED_TRACER=y CONFIG_SCSI_IPR_TRACE=y
CONFIG_STACKTRACE=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
== find /debugfs /proc /sys /dev -name '*kprobes*' 2>/dev/null | xargs
grep . ==
*********************************************************************
cat /proc/kallsyms | grep setup_fail_slab
nm /lib/modules/2.6.24-FNM_v2.1/build/vmlinux | grep setup_fail_slab
give no output
*********************************************************************
readelf,,,
There are 49 section headers, starting at offset 0x3a6e260:
Section Headers:
[Nr] Name Type Addr Off Size ES
Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .text.head PROGBITS c0100000 001000 00037a 00
AX 0 0 4
[ 2] .text PROGBITS c0101000 002000 3f635a 00
AX 0 0 4096
[ 3] __ex_table PROGBITS c04f7360 3f8360 000e80 00
A 0 0 8
[ 4] .notes NOTE c04f81e0 3f91e0 000024 00
AX 0 0 4
[ 5] __bug_table PROGBITS c04f8208 3f9208 006cc0 00
A 0 0 1
[ 6] .rodata PROGBITS c04ff000 400000 140665 00
A 0 0 128
[ 7] .pci_fixup PROGBITS c063f668 540668 0008c0 00
A 0 0 4
[ 8] __ksymtab PROGBITS c063ff28 540f28 005ef8 00
A 0 0 4
[ 9] __ksymtab_gpl PROGBITS c0645e20 546e20 001f18 00
A 0 0 4
[10] __ksymtab_unused_ PROGBITS c0647d38 548d38 000010 00
A 0 0 4
[11] __ksymtab_gpl_fut PROGBITS c0647d48 548d48 000018 00
A 0 0 4
[12] __kcrctab PROGBITS c0647d60 548d60 002f7c 00
A 0 0 4
[13] __kcrctab_gpl PROGBITS c064acdc 54bcdc 000f8c 00
A 0 0 4
[14] __kcrctab_unused_ PROGBITS c064bc68 54cc68 000008 00
A 0 0 4
[15] __kcrctab_gpl_fut PROGBITS c064bc70 54cc70 00000c 00
A 0 0 4
[16] __ksymtab_strings PROGBITS c064bc80 54cc80 011c53 00
A 0 0 32
[17] __param PROGBITS c065d8d4 55e8d4 000ba4 00
A 0 0 4
[18] .data PROGBITS c065f000 560000 03de08 00
WA 0 0 128
[19] .data_nosave PROGBITS c069d000 59e000 001000 00
WA 0 0 4096
[20] .data.page_aligne PROGBITS c069e000 59f000 000800 00
WA 0 0 32
[21] .data.cacheline_a PROGBITS c069e800 59f800 0163ac 00
WA 0 0 128
[22] .data.read_mostly PROGBITS c06b4c00 5b5c00 002494 00
WA 0 0 128
[23] .data.init_task PROGBITS c06b8000 5b9000 001000 00
WA 0 0 32
[24] .smp_locks PROGBITS c06b9000 5ba000 003f94 00
A 0 0 4
[25] .init.text PROGBITS c06bd000 5be000 02aea8 00
AX 0 0 16
[26] .init.data PROGBITS c06e7ec0 5e8ec0 020172 00
WA 0 0 32
[27] .init.setup PROGBITS c0708040 609040 0006e4 00
WA 0 0 4
[28] .initcall.init PROGBITS c0708724 609724 0004dc 00
WA 0 0 4
[29] .con_initcall.ini PROGBITS c0708c00 609c00 000008 00
WA 0 0 4
[30] .altinstructions PROGBITS c0708c08 609c08 00bcf3 00
A 0 0 4
[31] .altinstr_replace PROGBITS c07148fb 6158fb 003011 00
AX 0 0 1
[32] .exit.text PROGBITS c0717910 618910 001902 00
AX 0 0 16
[33] .init.ramfs PROGBITS c071a000 61b000 000084 00
A 0 0 1
[34] .data.percpu PROGBITS c071b000 61c000 00663c 00
WA 0 0 4096
[35] .bss NOBITS c0722000 62263c 09b000 00
WA 0 0 4096
[36] .comment PROGBITS 00000000 62263c 00af4e 00
0 0 1
[37] .debug_aranges PROGBITS 00000000 62d590 00bad8 00
0 0 8
[38] .debug_pubnames PROGBITS 00000000 639068 04083b 00
0 0 1
[39] .debug_info PROGBITS 00000000 6798a3 293841c 00
0 0 1
[40] .debug_abbrev PROGBITS 00000000 2fb1cbf 1400b2 00
0 0 1
[41] .debug_line PROGBITS 00000000 30f1d71 2bb041 00
0 0 1
[42] .debug_frame PROGBITS 00000000 33acdb4 08607c 00
0 0 4
[43] .debug_str PROGBITS 00000000 3432e30 1224e0 01
MS 0 0 1
[44] .debug_loc PROGBITS 00000000 3555310 417d3f 00
0 0 1
[45] .debug_ranges PROGBITS 00000000 396d050 100fa0 00
0 0 8
[46] .shstrtab STRTAB 00000000 3a6dff0 00026d 00
0 0 1
[47] .symtab SYMTAB 00000000 3a6ea08 0ac3d0 10
48 30206 4
[48] .strtab STRTAB 00000000 3b1add8 0e0251 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
*******************************************************************************
CONFIG_DEBUG_INFO=y (in /boot/config)
******************************************************************************
With kprobe.function("setup_fail_slab") the semantic error persists.
Thank you.
Quoting "Frank Ch. Eigler" <fche@redhat.com>:
> Hi -
>
>> parse 'setup_fail_slab@mm/slab.c', func 'setup_fail_slab', file 'mm/slab.c'
>> focused on module 'kernel' = [0x0xc0100000, -0x0xc07bd000, bias 0x0
>> file /lib/modules/2.6.24-FNM_v2.1/build/vmlinux ELF machine i?86|
>> (code 3)
>> [...]
>> semantic error: no match while resolving probe point
>> kernel.function("setup_fail_slab@mm/slab.c").call
>> parse 'setup_fail_slab@mm/slab.c', func 'setup_fail_slab', file 'mm/slab.c'
>> [...]
>
> Can you run
> stap-report
> cat /proc/kallsyms | grep setup_fail_slab
> nm /lib/modules/2.6.24-FNM_v2.1/build/vmlinux | grep setup_fail_slab
> readelf -S /lib/modules/2.6.24-FNM_v2.1/build/vmlinux
> Can you try kprobe.function("setup_fail_slab") instead of kernel.function()?
> (I'm wondering if you're lacking CONFIG_DEBUG_INFO.)
>
> - FChE
>
>
Domenico Di Leo, PhD student, Universit? degli Studi di Napoli Federico II
Ph: +39 081 676770
Fax: +39 081 676574
Web: http://wpage.unina.it/domenico.dileo
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: semantic error
2012-09-20 15:42 ` domenico.dileo
@ 2012-09-26 16:09 ` Frank Ch. Eigler
2012-09-26 19:35 ` domenico.dileo
0 siblings, 1 reply; 11+ messages in thread
From: Frank Ch. Eigler @ 2012-09-26 16:09 UTC (permalink / raw)
To: domenico.dileo; +Cc: systemtap
Hi -
> parse 'setup_fail_slab@mm/slab.c', func 'setup_fail_slab', file 'mm/slab.c'
> focused on module 'kernel' = [0x0xc0100000, -0x0xc07bd000, bias 0x0
> file /lib/modules/2.6.24-FNM_v2.1/build/vmlinux ELF machine i?86|
> (code 3)
> [...]
> semantic error: no match while resolving probe point
> kernel.function("setup_fail_slab@mm/slab.c").call
> parse 'setup_fail_slab@mm/slab.c', func 'setup_fail_slab', file 'mm/slab.c'
> [...]
Can you run
stap-report
cat /proc/kallsyms | grep setup_fail_slab
nm /lib/modules/2.6.24-FNM_v2.1/build/vmlinux | grep setup_fail_slab
readelf -S /lib/modules/2.6.24-FNM_v2.1/build/vmlinux
Can you try kprobe.function("setup_fail_slab") instead of kernel.function()?
(I'm wondering if you're lacking CONFIG_DEBUG_INFO.)
- FChE
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: semantic error
2012-09-20 1:54 ` Frank Ch. Eigler
@ 2012-09-20 15:42 ` domenico.dileo
2012-09-26 16:09 ` Frank Ch. Eigler
0 siblings, 1 reply; 11+ messages in thread
From: domenico.dileo @ 2012-09-20 15:42 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: systemtap
Dear Frank,
Despite your suggestion of removing the @FILE part
from the probe point command, I still receive the same
error.
Hereafter, there are some errors prompted by systemtap
when the option --vp 3 is enabled.
parse 'setup_fail_slab@mm/slab.c', func 'setup_fail_slab', file 'mm/slab.c'
focused on module 'kernel' = [0x0xc0100000, -0x0xc07bd000, bias 0x0
file /lib/modules/2.6.24-FNM_v2.1/build/vmlinux ELF machine i?86|
(code 3)
focused on module 'kernel'
selected source file 'mm/slab.c'
semantic error: no match while resolving probe point
kernel.function("setup_fail_slab@mm/slab.c").call
parse 'setup_fail_slab@mm/slab.c', func 'setup_fail_slab', file 'mm/slab.c'
focused on module 'kernel' = [0x0xc0100000, -0x0xc07bd000, bias 0x0
file /lib/modules/2.6.24-FNM_v2.1/build/vmlinux ELF machine i?86|
(code 3)
focused on module 'kernel'
selected source file 'mm/slab.c'
semantic error: no match while resolving probe point
kernel.function("setup_fail_slab@mm/slab.c").return
parse 'should_fail_alloc_page@mm/page_alloc.c', func
'should_fail_alloc_page', file 'mm/page_alloc.c'
focused on module 'kernel' = [0x0xc0100000, -0x0xc07bd000, bias 0x0
file /lib/modules/2.6.24-FNM_v2.1/build/vmlinux ELF machine i?86|
(code 3)
Quoting "Frank Ch. Eigler" <fche@redhat.com>:
>
> Hi, Domenico -
>
> domenico.dileo wrote:
>
>> I would like to set a probe point for the following functions:
>> [...]
>> should_fail_request@block/ll_rw_blk.c
>> should_fail_slab@mm/slab.c
>> fail_slab_debug_fs@mm/slab.c
>> [...]
>> in order to assign a probe to them, I use the command
>> probe kernel.function("fail_make_request_debugfs@block/ll_rw_blk.c").call
>> [...]
>
> Try just
> kernel.function("fail_make_request_debugfs").call
> and so on (drop the @FILE part), just in case that's not quite right.
> Try
> stap --vp 03 -e 'probe ....'
> to get way more information about stap's processing of the probe points.
>
> - FChE
>
>
Domenico Di Leo, PhD student, Universit? degli Studi di Napoli Federico II
Ph: +39 081 676770
Fax: +39 081 676574
Web: http://wpage.unina.it/domenico.dileo
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: semantic error
2012-09-19 22:03 domenico.dileo
@ 2012-09-20 1:54 ` Frank Ch. Eigler
2012-09-20 15:42 ` domenico.dileo
0 siblings, 1 reply; 11+ messages in thread
From: Frank Ch. Eigler @ 2012-09-20 1:54 UTC (permalink / raw)
To: domenico.dileo; +Cc: systemtap
Hi, Domenico -
domenico.dileo wrote:
> I would like to set a probe point for the following functions:
> [...]
> should_fail_request@block/ll_rw_blk.c
> should_fail_slab@mm/slab.c
> fail_slab_debug_fs@mm/slab.c
> [...]
> in order to assign a probe to them, I use the command
> probe kernel.function("fail_make_request_debugfs@block/ll_rw_blk.c").call
> [...]
Try just
kernel.function("fail_make_request_debugfs").call
and so on (drop the @FILE part), just in case that's not quite right.
Try
stap --vp 03 -e 'probe ....'
to get way more information about stap's processing of the probe points.
- FChE
^ permalink raw reply [flat|nested] 11+ messages in thread
* semantic error
@ 2012-09-19 22:03 domenico.dileo
2012-09-20 1:54 ` Frank Ch. Eigler
0 siblings, 1 reply; 11+ messages in thread
From: domenico.dileo @ 2012-09-19 22:03 UTC (permalink / raw)
To: systemtap
I would like to set a probe point for the following functions:
fail_make_request_debugfs@block/ll_rw_blk.c
should_fail_request@block/ll_rw_blk.c
should_fail_slab@mm/slab.c
fail_slab_debug_fs@mm/slab.c
These functions are enabled only if the kernel
is configure with fault injection modules (e.g.,
in the . config the CONFIG_FAIL_SLAB = y)
in order to assign a probe to them, I use the command
probe kernel.function("fail_make_request_debugfs@block/ll_rw_blk.c").call
Similarly for the other functions.
When running, stap prompts the error message "semantic error no match
while resolving probe points... "
Additional notes:
- The former functions appear as symbols in
proc/kallsyms.
- I use stap_v1.6 and a linux kernel 2.6.24.
Thank you for your help.
Domenico Di Leo, PhD student, Universit? degli Studi di Napoli Federico II
Ph: +39 081 676770
Fax: +39 081 676574
Web: http://wpage.unina.it/domenico.dileo
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-01-22 9:35 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-21 14:36 semantic error Mehul Choube
2013-01-21 15:06 ` Frank Ch. Eigler
2013-01-21 15:43 ` Mehul Choube
2013-01-21 16:23 ` Frank Ch. Eigler
2013-01-22 9:35 ` Mehul Choube
-- strict thread matches above, loose matches on Subject: below --
2012-09-19 22:03 domenico.dileo
2012-09-20 1:54 ` Frank Ch. Eigler
2012-09-20 15:42 ` domenico.dileo
2012-09-26 16:09 ` Frank Ch. Eigler
2012-09-26 19:35 ` domenico.dileo
2012-09-27 21:01 ` domenico.dileo
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).