This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Test suite results for ARM with uprobes
Hi Mark,
Thanks for your analysis!
Mark Wielaard wrote:
> On Tue, 2011-12-06 at 12:45 -0700, Wade Farnsworth wrote:
[...]
First, four tests are causing hangs, panics or other kernel errors.
In general I found that arm kernels pre-3.0 (2.6.40 in fedora speak)
were somewhat unstable. There were lots of kprobe cleanups in 3.0.
Ah, yes. You did mention that previously. I'll see about retesting
with something more recent.
[...]
FAIL: debugpath-good (eof) [This one puzzles me. I've built with
CONFIG_DEBUG_INFO enabled and the build directory exists in
/lib/modules/`uname -r`/build. Is there something else that I need to
do to get systemtap access to the debug info?]
It fails because:
spawn env SYSTEMTAP_DEBUGINFO_PATH=/lib/modules/2.6.37.6-yocto-standard+/build s
tap -e probe kernel.function("vfs_read") {} -wp2
semantic error: missing arm kernel/module debuginfo under '/lib/modules/2.6.37.6
-yocto-standard+/build' while resolving probe point kernel.function("vfs_read")
Pass 2: analysis failed. Try again with another '--vp 01' option.
FAIL: debugpath-good (eof)
It PASSes for me with:
spawn env SYSTEMTAP_DEBUGINFO_PATH=/usr/lib/debug stap -e probe kernel.function(
"vfs_read") {} -wp2
# probes
kernel.function("vfs_read@fs/read_write.c:306") /* pc=_stext+0x1445e0 */ /*<- k
ernel.function("vfs_read") */
PASS: debugpath-good
The debugpath.exp testcase does:
# Guess where debuginfo is installed
if [file isdirectory /usr/lib/debug] {
set debuginfo_path "/usr/lib/debug"
} elseif [file isdirectory /lib/modules/$uname/build] {
set debuginfo_path "/lib/modules/$uname/build"
} else {
set debuginfo_path "/lib/modules/$uname"
}
So, I guess it is guessing wrongly?
Hmm, I do have the debuginfo-enabled vmlinux in
/lib/modules/2.6.37.6-yocto-standard+/build, which stap seems to
otherwise be able to find. For some reason it seems to only occur when
SYSTEMTAP_DEBUGINFO_PATH is used. I'll do some more digging.
[...]
FAIL: inlinedvars-m32-O
FAIL: inlinedvars-m32-O2
[line 1: expected "call (22,84)"
Got " (84,22)"]
That is interesting, it switches the numbers around?
It obviously doesn't run for me. It would be interesting to see the
debuginfo debug-dump of the created binary, the disassembly of function
"m" and the generated stap script C source code. Could you create a bug
report with that info in it?
Done. http://sourceware.org/bugzilla/show_bug.cgi?id=13485
[...]
FAIL: sdt -O2 uprobe
FAIL: sdt c89 uprobe
FAIL: sdt c99 uprobe
FAIL: sdt c99 -pedantic uprobe
FAIL: sdt gnu99 uprobe
FAIL: sdt gnu99 -pedantic uprobe
FAIL: sdt c++98 uprobe
FAIL: sdt c++98 -pedantic uprobe
FAIL: sdt gnu++98 uprobe
FAIL: sdt gnu++98 -pedantic uprobe
FAIL: sdt c++0x uprobe
FAIL: sdt c++0x -pedantic uprobe
FAIL: sdt gnu++0x uprobe
FAIL: sdt gnu++0x -pedantic uprobe
[semantic error: unable to find local 'arg1' near pc 0x8408 in call1
/home/root/stuff/systemtap/testsuite/systemtap.base/sdt.c (
(alternatives: $a): identifier '$arg1' at
/home/root/stuff/systemtap/testsuite/systemtap.base/sdt.stp:8:18.]
FAIL: sdt_va_args base
FAIL: sdt_va_args c89
FAIL: sdt_va_args c99
FAIL: sdt_va_args gnu99
FAIL: sdt_va_args c++98
FAIL: sdt_va_args gnu++98
FAIL: sdt_va_args c++0x
FAIL: sdt_va_args gnu++0x
[similar to the sdt failures above]
I am unable to run these tests, but it would be interesting to see
debuginfo dump, disassembly and generated stap script C source for
these.
The failure occurs before the C source is generated I have uploaded the
other info to:
http://dl.dropbox.com/u/40714612/stap-debug-files.tar.gz
[...]
FAIL: vta-test-m32-O
FAIL: vta-test-m32-O2
[semantic error: failed to retrieve location attribute for local 'a'
(dieoffset: 0x181): identifier '$a' at
/home/root/stuff/systemtap/testsuite/systemtap.base/vta-test.stp:2:27]
I cannot run this tests. It would be interesting to see the debuginfo
dump for the generated binary.
Also in the tarball on dropbox.
[...]
FAIL: buildok/seventeen.stp [semantic error: unable to find local
'nfs_program' near pc 0xc01bc714 in nfs_fsync_dir]
This one does PASS for me. We should probably compare generated
debuginfo for our kernels.
Kernel debuginfo is also in the tarball.
[...]
FAIL: semok/config_number.stp [semantic error: probe point mismatch at
position 0]
This one PASSes for me.
What is CONFIG_NR_CPU set to for your kernel?
It is set to 2 for me.
CONFIG_SMP is not set, so CONFIG_NR_CPU doesn't exist in my config file.
Maybe stap treats that as being equal to zero?
I'll keep poking at the other failures. Thanks again!
Regards,
-Wade Farnsworth