Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Pavan Naregundi]

Hi,

Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

Arch: ppc64

Please contact me, for any other details.

  === systemtap Summary ===

# of expected passes            647
# of unexpected failures        63
# of unexpected successes       9
# of expected failures          195
# of unknown successes          1
# of known failures             6
# of untested testcases         50
# of unsupported tests          2


Unexpected failures
=============================
FAIL: LOCAL1 (0)
FAIL: STRUCT1 (0)
FAIL: backtrace (1 0)
FAIL: backtrace-unwindsyms (1 0)
FAIL: systemtap.base/cast.stp
FAIL: debugpath-bad (eof)
FAIL: debugpath-good (eof)
FAIL: gtod (9)
FAIL: MAXACTIVE01 compilation
FAIL: MAXACTIVE02 compilation
FAIL: conditional probes (0)
FAIL: OVERLOAD1 compilation
FAIL: OVERLOAD2 compilation
FAIL: OVERLOAD3 compilation
FAIL: compiling sdt.c ""
FAIL: compiling sdt.c additional_flags=-std=gnu89
FAIL: compiling sdt.c additional_flags=-ansi
FAIL: compiling sdt.c additional_flags=-pedantic
FAIL: compiling sdt.c additional_flags=-ansi additional_flags=-pedantic
FAIL: compiling sdt.c additional_flags=-O2
FAIL: compiling sdt.c additional_flags="-O3"
FAIL: static_uprobes compiling C -g
FAIL: stmtvars - .function
FAIL: system_func (0,0,0)
FAIL: backtrace of yyy_func2 (1)
FAIL: print_stack of yyy_func2 (1)
FAIL: backtrace of yyy_func3 (1)
FAIL: print_stack of yyy_func3 (1)
FAIL: backtrace of yyy_func4 (1)
FAIL: print_stack of yyy_func4 (1)
FAIL: integer function arguments -- numeric
FAIL: unsigned function arguments -- numeric
FAIL: long function arguments -- numeric
FAIL: int64 function arguments -- numeric
FAIL: char function arguments -- numeric
FAIL: string function arguments -- numeric
FAIL: integer function arguments -- numeric --kelf --ignore-dwarf
FAIL: unsigned function arguments -- numeric --kelf --ignore-dwarf
FAIL: long function arguments -- numeric --kelf --ignore-dwarf
FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf
FAIL: char function arguments -- numeric --kelf --ignore-dwarf
FAIL: string function arguments -- numeric --kelf --ignore-dwarf
FAIL: systemtap.examples/general/para-callgraph build
FAIL: systemtap.examples/general/para-callgraph run
FAIL: buildok/maxactive01.stp
FAIL: buildok/signal-all-probes.stp
FAIL: buildok/thirteen.stp
FAIL: semok/thirtytwo.stp
FAIL: semok/twentyeight.stp
FAIL: semok/twentyfour.stp
FAIL: semok/twentynine.stp
FAIL: semok/twentyseven.stp
FAIL: systemtap.printf/bin6.stp
FAIL: systemtap.stress/current.stp shutdown (eof)
FAIL: 64-bit acct
FAIL: 64-bit net1
FAIL: 64-bit readwrite
FAIL: 64-bit signal
FAIL: 32-bit acct
FAIL: 32-bit net1
FAIL: 32-bit readwrite
FAIL: 32-bit signal
FAIL: 32-bit statfs
================

Thanks
Pavan
-------------------------------------------------------------------
Linux Technology Center
IBM India Software Labs
Bangalore
-------------------------------------------------------------------

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Mark Wielaard]

Hi Pavan,

On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote:
> Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
> Arch: ppc64
>
> Please contact me, for any other details.

Thanks for testing this combination. Which elfutils version did you use?

> Unexpected failures
> =============================
> FAIL: LOCAL1 (0)

I have seen this fail sporadically, is it failing always for you?

> FAIL: STRUCT1 (0)

Could you post the relevant part of the testsuite/systemtap.log?

> FAIL: backtrace (1 0)
> FAIL: backtrace-unwindsyms (1 0)

This is http://sourceware.org/bugzilla/show_bug.cgi?id=6961
"backtrace from non-pt_regs probe context"

> FAIL: systemtap.base/cast.stp
> FAIL: debugpath-bad (eof)
> FAIL: debugpath-good (eof)

Could you post the relevant parts of the testsuite/systemtap.log for the
above failures?

> FAIL: gtod (9)

This is probably http://sourceware.org/bugzilla/show_bug.cgi?id=5094
"gtod.exp fails on ppc64/i386"

> FAIL: MAXACTIVE01 compilation
> FAIL: MAXACTIVE02 compilation
> FAIL: conditional probes (0)
> FAIL: OVERLOAD1 compilation
> FAIL: OVERLOAD2 compilation
> FAIL: OVERLOAD3 compilation

Could you post the relevant parts of the testsuite/systemtap.log for the
above failures?

> FAIL: compiling sdt.c ""
> FAIL: compiling sdt.c additional_flags=-std=gnu89
> FAIL: compiling sdt.c additional_flags=-ansi
> FAIL: compiling sdt.c additional_flags=-pedantic
> FAIL: compiling sdt.c additional_flags=-ansi additional_flags=-pedantic
> FAIL: compiling sdt.c additional_flags=-O2
> FAIL: compiling sdt.c additional_flags="-O3"
> FAIL: static_uprobes compiling C -g

That probably means the sdt.h header doesn't compile on ppc.
Could you see if testsuite/systemtap.log gives more hints about what is
wrong? What gcc version are you using?

> FAIL: stmtvars - .function
> FAIL: system_func (0,0,0)

Could you post the relevant parts of the testsuite/systemtap.log for the
above failures?

> FAIL: backtrace of yyy_func2 (1)
> FAIL: print_stack of yyy_func2 (1)
> FAIL: backtrace of yyy_func3 (1)
> FAIL: print_stack of yyy_func3 (1)
> FAIL: backtrace of yyy_func4 (1)
> FAIL: print_stack of yyy_func4 (1)

These might need support for the dwarf unwinder on ppc to provide more
accurate backtraces.
http://sourceware.org/ml/systemtap/2009-q2/msg00307.html

> FAIL: integer function arguments -- numeric
> FAIL: unsigned function arguments -- numeric
> FAIL: long function arguments -- numeric
> FAIL: int64 function arguments -- numeric
> FAIL: char function arguments -- numeric
> FAIL: string function arguments -- numeric
> FAIL: integer function arguments -- numeric --kelf --ignore-dwarf
> FAIL: unsigned function arguments -- numeric --kelf --ignore-dwarf
> FAIL: long function arguments -- numeric --kelf --ignore-dwarf
> FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf
> FAIL: char function arguments -- numeric --kelf --ignore-dwarf
> FAIL: string function arguments -- numeric --kelf --ignore-dwarf

Could you post the relevant parts of the testsuite/systemtap.log for the
above failures?

> FAIL: systemtap.examples/general/para-callgraph build
> FAIL: systemtap.examples/general/para-callgraph run

Likewise.

> FAIL: buildok/maxactive01.stp
> FAIL: buildok/signal-all-probes.stp
> FAIL: buildok/thirteen.stp
> FAIL: semok/thirtytwo.stp
> FAIL: semok/twentyeight.stp
> FAIL: semok/twentyfour.stp
> FAIL: semok/twentynine.stp
> FAIL: semok/twentyseven.stp
> FAIL: systemtap.printf/bin6.stp
> FAIL: systemtap.stress/current.stp shutdown (eof)


Some of these might be solved with an updated elfutils (0.141). At least
that was the case for s390.

> FAIL: 64-bit acct
> FAIL: 64-bit net1
> FAIL: 64-bit readwrite
> FAIL: 64-bit signal
> FAIL: 32-bit acct
> FAIL: 32-bit net1
> FAIL: 32-bit readwrite
> FAIL: 32-bit signal
> FAIL: 32-bit statfs

The net1 failures are
http://sourceware.org/bugzilla/show_bug.cgi?id=6991
"accept system call missed on 2.6.27"

For the others look in the systemtap.log file and/or try running the
tests in testsuite/systemtap.syscall by hand. There is a README there
explaining how the tests work and how to use the tcl framework to see
how things should match.

Thanks,

Mark

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Pavan Naregundi]

Mark Wielaard <mjw@redhat.com> wrote on 04/27/2009 08:12:50 PM:

> From:
>
> Mark Wielaard <mjw@redhat.com>
>
> To:
>
> Pavan Naregundi/India/IBM@IBMIN
>
> Cc:
>
> systemtap@sourceware.org
>
> Date:
>
> 04/27/2009 08:10 PM
>
> Subject:
>
> Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
>
> Hi Pavan,
>
> On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote:
> > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
> > Arch: ppc64
> >
> > Please contact me, for any other details.
>
> Thanks for testing this combination. Which elfutils version did you use?

It is elfutils-0.141.tar.bz2..

>
> > Unexpected failures
> > =============================
> > FAIL: LOCAL1 (0)
>
> I have seen this fail sporadically, is it failing always for you?
>
> > FAIL: STRUCT1 (0)
>
> Could you post the relevant part of the testsuite/systemtap.log?
>
> > FAIL: backtrace (1 0)
> > FAIL: backtrace-unwindsyms (1 0)
>
> This is http://sourceware.org/bugzilla/show_bug.cgi?id=6961
> "backtrace from non-pt_regs probe context"
>
> > FAIL: systemtap.base/cast.stp
> > FAIL: debugpath-bad (eof)
> > FAIL: debugpath-good (eof)
>
> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?
>
> > FAIL: gtod (9)
>
> This is probably http://sourceware.org/bugzilla/show_bug.cgi?id=5094
> "gtod.exp fails on ppc64/i386"
>
> > FAIL: MAXACTIVE01 compilation
> > FAIL: MAXACTIVE02 compilation
> > FAIL: conditional probes (0)
> > FAIL: OVERLOAD1 compilation
> > FAIL: OVERLOAD2 compilation
> > FAIL: OVERLOAD3 compilation
>
> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?
>
> > FAIL: compiling sdt.c ""
> > FAIL: compiling sdt.c additional_flags=-std=gnu89
> > FAIL: compiling sdt.c additional_flags=-ansi
> > FAIL: compiling sdt.c additional_flags=-pedantic
> > FAIL: compiling sdt.c additional_flags=-ansi additional_flags=-pedantic
> > FAIL: compiling sdt.c additional_flags=-O2
> > FAIL: compiling sdt.c additional_flags="-O3"
> > FAIL: static_uprobes compiling C -g
>
> That probably means the sdt.h header doesn't compile on ppc.
> Could you see if testsuite/systemtap.log gives more hints about what is
> wrong? What gcc version are you using?
>
> > FAIL: stmtvars - .function
> > FAIL: system_func (0,0,0)
>
> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?
>
> > FAIL: backtrace of yyy_func2 (1)
> > FAIL: print_stack of yyy_func2 (1)
> > FAIL: backtrace of yyy_func3 (1)
> > FAIL: print_stack of yyy_func3 (1)
> > FAIL: backtrace of yyy_func4 (1)
> > FAIL: print_stack of yyy_func4 (1)
>
> These might need support for the dwarf unwinder on ppc to provide more
> accurate backtraces.
> http://sourceware.org/ml/systemtap/2009-q2/msg00307.html
>
> > FAIL: integer function arguments -- numeric
> > FAIL: unsigned function arguments -- numeric
> > FAIL: long function arguments -- numeric
> > FAIL: int64 function arguments -- numeric
> > FAIL: char function arguments -- numeric
> > FAIL: string function arguments -- numeric
> > FAIL: integer function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: unsigned function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: long function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: char function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: string function arguments -- numeric --kelf --ignore-dwarf
>
> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?
>
> > FAIL: systemtap.examples/general/para-callgraph build
> > FAIL: systemtap.examples/general/para-callgraph run
>
> Likewise.
>
> > FAIL: buildok/maxactive01.stp
> > FAIL: buildok/signal-all-probes.stp
> > FAIL: buildok/thirteen.stp
> > FAIL: semok/thirtytwo.stp
> > FAIL: semok/twentyeight.stp
> > FAIL: semok/twentyfour.stp
> > FAIL: semok/twentynine.stp
> > FAIL: semok/twentyseven.stp
> > FAIL: systemtap.printf/bin6.stp
> > FAIL: systemtap.stress/current.stp shutdown (eof)
>
>
> Some of these might be solved with an updated elfutils (0.141). At least
> that was the case for s390.
>
> > FAIL: 64-bit acct
> > FAIL: 64-bit net1
> > FAIL: 64-bit readwrite
> > FAIL: 64-bit signal
> > FAIL: 32-bit acct
> > FAIL: 32-bit net1
> > FAIL: 32-bit readwrite
> > FAIL: 32-bit signal
> > FAIL: 32-bit statfs
>
> The net1 failures are
> http://sourceware.org/bugzilla/show_bug.cgi?id=6991
> "accept system call missed on 2.6.27"
>
> For the others look in the systemtap.log file and/or try running the
> tests in testsuite/systemtap.syscall by hand. There is a README there
> explaining how the tests work and how to use the tcl framework to see
> how things should match.
>
> Thanks,
>
> Mark
>

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Pavan Naregundi]

Mark Wielaard <mjw@redhat.com> wrote on 04/27/2009 08:12:50 PM:

> From:
>
> Mark Wielaard <mjw@redhat.com>
>
> To:
>
> Pavan Naregundi/India/IBM@IBMIN
>
> Cc:
>
> systemtap@sourceware.org
>
> Date:
>
> 04/27/2009 08:10 PM
>
> Subject:
>
> Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
>
> Hi Pavan,
>
> On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote:
> > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
> > Arch: ppc64
> >
> > Please contact me, for any other details.
>
> Thanks for testing this combination. Which elfutils version did you use?

elfutils-0.141

>
> > Unexpected failures
> > =============================
> > FAIL: LOCAL1 (0)
>
> I have seen this fail sporadically, is it failing always for you?
I have seen this every time.

>
> > FAIL: STRUCT1 (0)
>
> Could you post the relevant part of the testsuite/systemtap.log?

Running /home/pavan/systemtap/src/testsuite/systemtap.base/alternatives.exp
...
starting stap -vu -p2 -e {
    probe kernel.function("sys_getrlimit") { x = $z; }
}
Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real
ms.^M
Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real
ms.^M
wait results: 15196 exp6 0 1
FAIL: LOCAL1 (0)
starting stap -vu -p2 -e {
    probe kernel.function("sys_getrlimit") { rlim_cur = $rlim->rlim_cud; }
}
Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/345real
ms.^M
Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/345real
ms.^M
semantic error: no match while resolving probe point
kernel.function("sys_getrlimit")^M

semantic error: no match while resolving probe point
kernel.function("sys_getrlimit")^M
semantic error: no probes found^M
Pass 2: analyzed script:
semantic error: no probes found^M
0 probe(s), 0 function(s), 0 embed(s), 0 global(s) in
1430usr/960sys/2385real ms.^M
Pass 2: analysis failed.  Try again with another '--vp 01' option.^M

Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 global(s)
in 1430usr/960sys/2385real ms.^M

Pass 2: analysis failed.  Try again with another '--vp 01' option.^M
wait results: 15216 exp7 0 1
FAIL: STRUCT1 (0)
testcase
/home/pavan/systemtap/src/testsuite/systemtap.base/alternatives.exp
completed in 114 seconds

>
> > FAIL: backtrace (1 0)
> > FAIL: backtrace-unwindsyms (1 0)
>
> This is http://sourceware.org/bugzilla/show_bug.cgi?id=6961
> "backtrace from non-pt_regs probe context"
>
> > FAIL: systemtap.base/cast.stp
> > FAIL: debugpath-bad (eof)
> > FAIL: debugpath-good (eof)
>
> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?

Running /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp ...
executing: stap /home/pavan/systemtap/src/testsuite/systemtap.base/cast.stp
-g
FAIL: systemtap.base/cast.stp
line 4: expected "tv_sec OK"
Got "tv_sec 42 != 0"
testcase /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp
completed in 8 seconds


Running /home/pavan/systemtap/src/testsuite/systemtap.base/debugpath.exp
...
semantic error: no match while resolving probe point
kernel.function("sys_open")^M
semantic error: no probes found^M
Pass 2: analysis failed.  Try again with another '--vp 01' option.^M
FAIL: debugpath-bad (eof)
semantic error: no match while resolving probe point
kernel.function("sys_open")^M
semantic error: no probes found^M
Pass 2: analysis failed.  Try again with another '--vp 01' option.^M
FAIL: debugpath-good (eof)
testcase /home/pavan/systemtap/src/testsuite/systemtap.base/debugpath.exp
completed in 6 seconds


>
> > FAIL: gtod (9)
>
> This is probably http://sourceware.org/bugzilla/show_bug.cgi?id=5094
> "gtod.exp fails on ppc64/i386"
>
> > FAIL: MAXACTIVE01 compilation
> > FAIL: MAXACTIVE02 compilation

Running /home/pavan/systemtap/src/testsuite/systemtap.base/maxactive.exp
...
executing: stap -v -e {
    global foo
    probe kernel.function("sys_select").return,
        kernel.function("sys_read").return { foo++ }

    probe timer.ms(5000) { exit(); }
    probe begin { log("systemtap starting probe"); log("systemtap ending
probe");}
}
Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/346real
ms.^M
semantic error: no match while resolving probe point
kernel.function("sys_select").returnFAIL: MAXACTIVE01 compilation
executing: stap -v -e {
    global foo
    probe kernel.function("sys_select").return.maxactive(1),
        kernel.function("sys_read").return.maxactive(1) { foo++ }

    probe timer.ms(5000) { exit(); }
    probe begin { log("systemtap starting probe"); log("systemtap ending
probe");}
}
Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/347real
ms.^M
semantic error: no match while resolving probe point
kernel.function("sys_select").return.maxactive(1)FAIL: MAXACTIVE02
compilation
PASS: MAXACTIVE03
testcase /home/pavan/systemtap/src/testsuite/systemtap.base/maxactive.exp
completed in 6 seconds

> > FAIL: conditional probes (0)

Running /home/pavan/systemtap/src/testsuite/systemtap.base/onoffprobe.exp
...
semantic error: no match while resolving probe point
kernel.function("sys_write").return if ((switch) == (1))^M
semantic error: no match while resolving probe point
kernel.function("sys_write") if ((switch) == (2))^M
Pass 2: analysis failed.  Try again with another '--vp 01' option.^M
FAIL: conditional probes (0)
testcase /home/pavan/systemtap/src/testsuite/systemtap.base/onoffprobe.exp
completed in 3 seconds

> > FAIL: OVERLOAD1 compilation
> > FAIL: OVERLOAD2 compilation
> > FAIL: OVERLOAD3 compilation
testcase
/home/pavan/systemtap/src/testsuite/systemtap.base/overflow_error.exp
completed in 5 seconds
Running /home/pavan/systemtap/src/testsuite/systemtap.base/overload.exp ...
Pass 1: parsed user script and 53 library script(s) in 330usr/20sys/353real
ms.^M
semantic error: no match while resolving probe point
kernel.function("sys_read")FAIL: OVERLOAD1 compilation
Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real
ms.^M
semantic error: no match while resolving probe point
kernel.function("sys_read")FAIL: OVERLOAD2 compilation
Pass 1: parsed user script and 53 library script(s) in 330usr/20sys/350real
ms.^M
semantic error: no match while resolving probe point
kernel.function("sys_read")FAIL: OVERLOAD3 compilation
testcase /home/pavan/systemtap/src/testsuite/systemtap.base/overload.exp
completed in 9 seconds

>
> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?
>
> > FAIL: compiling sdt.c ""
> > FAIL: compiling sdt.c additional_flags=-std=gnu89
> > FAIL: compiling sdt.c additional_flags=-ansi
> > FAIL: compiling sdt.c additional_flags=-pedantic
> > FAIL: compiling sdt.c additional_flags=-ansi additional_flags=-pedantic
> > FAIL: compiling sdt.c additional_flags=-O2
> > FAIL: compiling sdt.c additional_flags="-O3"
> > FAIL: static_uprobes compiling C -g

Running /home/pavan/systemtap/src/testsuite/systemtap.base/sdt.exp ...
Executing on host: gcc
/home/pavan/systemtap/src/testsuite/systemtap.base/sdt.c  -g
-I/home/pavan/systemtap/src/testsuite/../includes/sys -Wall -Wextra -Werror
-lm   -o sdt.c.exe.0    (timeout = 300)
/tmp/ccastHp6.s: Assembler messages:^M
/tmp/ccastHp6.s:57: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:116: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:179: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:246: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:317: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:392: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:471: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:554: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:640: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:729: Error: junk at end of line: `0'^M
compiler exited with status 1
output is:
/tmp/ccastHp6.s: Assembler messages:^M
/tmp/ccastHp6.s:57: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:116: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:179: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:246: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:317: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:392: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:471: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:554: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:640: Error: junk at end of line: `0'^M
/tmp/ccastHp6.s:729: Error: junk at end of line: `0'^M

FAIL: compiling sdt.c ""
UNTESTED: sdt ""

>
> That probably means the sdt.h header doesn't compile on ppc.
> Could you see if testsuite/systemtap.log gives more hints about what is
> wrong? What gcc version are you using?

gcc version 4.3.2 20081007 (Red Hat 4.3.2-6) (GCC)

>
> > FAIL: stmtvars - .function

Running /home/pavan/systemtap/src/testsuite/systemtap.base/stmtvars.exp ...
SystemTap translator/driver (version 0.9.7/0.141 non-git sources)^M
Copyright (C) 2005-2009 Red Hat, Inc. and others^M
This is free software; see the source for copying conditions.^M
Session arch: ppc64 release: 2.6.30-rc3-git2^M
Created temporary directory "/tmp/stapQQdYat"^M
Searched '/usr/local/share/systemtap/tapset/ppc64/*.stp', found 2^M
Searched '/usr/local/share/systemtap/tapset/*.stp', found 51^M
Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real
ms.^M
semantic error: no match while resolving probe point
kernel.function("sys_open")^M
semantic error: no probes found^M
Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 global(s)
in 1410usr/950sys/2361real ms.^M
Pass 2: analysis failed.  Try again with another '--vp 01' option.^M
Running rm -rf /tmp/stapQQdYat^M
pc=0 vars=
FAIL: stmtvars - .function
SystemTap translator/driver (version 0.9.7/0.141 non-git sources)^M
Copyright (C) 2005-2009 Red Hat, Inc. and others^M

> > FAIL: system_func (0,0,0)

Running /home/pavan/systemtap/src/testsuite/systemtap.base/system_func.exp
...
semantic error: no match while resolving probe point
kernel.function("sys_open")^M
Pass 2: analysis failed.  Try again with another '--vp 01' option.^M
FAIL: system_func (0,0,0)
testcase /home/pavan/systemtap/src/testsuite/systemtap.base/system_func.exp
completed in 2 seconds

>
> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?
>
> > FAIL: backtrace of yyy_func2 (1)
> > FAIL: print_stack of yyy_func2 (1)
> > FAIL: backtrace of yyy_func3 (1)
> > FAIL: print_stack of yyy_func3 (1)
> > FAIL: backtrace of yyy_func4 (1)
> > FAIL: print_stack of yyy_func4 (1)
>
> These might need support for the dwarf unwinder on ppc to provide more
> accurate backtraces.
> http://sourceware.org/ml/systemtap/2009-q2/msg00307.html
>
> > FAIL: integer function arguments -- numeric
> > FAIL: unsigned function arguments -- numeric
> > FAIL: long function arguments -- numeric
> > FAIL: int64 function arguments -- numeric
> > FAIL: char function arguments -- numeric
> > FAIL: string function arguments -- numeric
> > FAIL: integer function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: unsigned function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: long function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: char function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: string function arguments -- numeric --kelf --ignore-dwarf
>

sourcing:
/home/pavan/systemtap/src/testsuite/systemtap.context/num_args.tcl
READY^M
yyy_int -4611686018425998288 -4611686018425998288 -4611686018425998288^M
yyy_int returns 499^M
FAIL: integer function arguments -- numeric
yyy_uint 1389616 1389616 1389616^M
yyy_uint returns 499^M
FAIL: unsigned function arguments -- numeric
yyy_long -4611686018425998288 -4611686018425998288 -4611686018425998288^M
yyy_long returns 499^M
FAIL: long function arguments -- numeric
yyy_int64 -4611686018425998288 -4611686018425998288 -4611686018425998288^M
yyy_int64 returns 499^M
FAIL: int64 function arguments -- numeric
yyy_char 0 0 0^M
yyy_char returns Q^M
FAIL: char function arguments -- numeric
yyy_str
ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc-ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc-ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc^M
yyy_str returns XYZZY^M
FAIL: string function arguments -- numeric
READY^M
yyy_int -4611686018425998288 -4611686018425998288 -4611686018425998288^M
yyy_int returns 499^M
FAIL: integer function arguments -- numeric --kelf --ignore-dwarf
yyy_uint 1389616 1389616 1389616^M
yyy_uint returns 499^M
FAIL: unsigned function arguments -- numeric --kelf --ignore-dwarf
yyy_long -4611686018425998288 -4611686018425998288 -4611686018425998288^M
yyy_long returns 499^M
FAIL: long function arguments -- numeric --kelf --ignore-dwarf
yyy_int64 -4611686018425998288 -4611686018425998288 -4611686018425998288^M
yyy_int64 returns 499^M
FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf
yyy_char 0 0 0^M
yyy_char returns Q^M
FAIL: char function arguments -- numeric --kelf --ignore-dwarf
yyy_str
ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc-ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc-ûaÿØ|^H^B¦û<81>ÿà|<9b>#xû¡ÿèxc^M
yyy_str returns XYZZY^M
FAIL: string function arguments -- numeric --kelf --ignore-dwarf
as_root /bin/rm -f
/lib/modules/2.6.30-rc3-git2/kernel/systemtap_test_module1.ko
OUT
RC 0
as_root /sbin/rmmod systemtap_test_module1
OUT
RC 0
as_root /bin/rm -f
/lib/modules/2.6.30-rc3-git2/kernel/systemtap_test_module2.ko
OUT
RC 0
as_root /sbin/rmmod systemtap_test_module2
OUT
RC 0

> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?
>
> > FAIL: systemtap.examples/general/para-callgraph build
> > FAIL: systemtap.examples/general/para-callgraph run
>
> Likewise.
>
> > FAIL: buildok/maxactive01.stp
> > FAIL: buildok/signal-all-probes.stp
> > FAIL: buildok/thirteen.stp
> > FAIL: semok/thirtytwo.stp
> > FAIL: semok/twentyeight.stp
> > FAIL: semok/twentyfour.stp
> > FAIL: semok/twentynine.stp
> > FAIL: semok/twentyseven.stp
> > FAIL: systemtap.printf/bin6.stp
> > FAIL: systemtap.stress/current.stp shutdown (eof)
>
>
> Some of these might be solved with an updated elfutils (0.141). At least
> that was the case for s390.

Using the same elfutils-0.141.

>
> > FAIL: 64-bit acct
> > FAIL: 64-bit net1
> > FAIL: 64-bit readwrite
> > FAIL: 64-bit signal
> > FAIL: 32-bit acct
> > FAIL: 32-bit net1
> > FAIL: 32-bit readwrite
> > FAIL: 32-bit signal
> > FAIL: 32-bit statfs
>
> The net1 failures are
> http://sourceware.org/bugzilla/show_bug.cgi?id=6991
> "accept system call missed on 2.6.27"
>
> For the others look in the systemtap.log file and/or try running the
> tests in testsuite/systemtap.syscall by hand. There is a README there
> explaining how the tests work and how to use the tcl framework to see
> how things should match.
>
> Thanks,
>
> Mark
>

Thanks
Pavan

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Ananth N Mavinakayanahalli]

On Tue, Apr 28, 2009 at 11:30:09AM +0530, Pavan Naregundi wrote:
> Mark Wielaard <mjw@redhat.com> wrote on 04/27/2009 08:12:50 PM:
> 
> > From:
> >
> > Mark Wielaard <mjw@redhat.com>
> >
> > To:
> >
> > Pavan Naregundi/India/IBM@IBMIN
> >
> > Cc:
> >
> > systemtap@sourceware.org
> >
> > Date:
> >
> > 04/27/2009 08:10 PM
> >
> > Subject:
> >
> > Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
> >
> > Hi Pavan,
> >
> > On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote:
> > > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
> > > Arch: ppc64
> > >
> > > Please contact me, for any other details.
> >
> > Thanks for testing this combination. Which elfutils version did you use?
> 
> elfutils-0.141
> 
> >
> > > Unexpected failures
> > > =============================
> > > FAIL: LOCAL1 (0)
> >
> > I have seen this fail sporadically, is it failing always for you?
> I have seen this every time.
> 
> >
> > > FAIL: STRUCT1 (0)
> >
> > Could you post the relevant part of the testsuite/systemtap.log?
> 
> Running /home/pavan/systemtap/src/testsuite/systemtap.base/alternatives.exp
> ...
> starting stap -vu -p2 -e {
>     probe kernel.function("sys_getrlimit") { x = $z; }
> }
> Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real
> ms.^M
> Pass 1: parsed user script and 53 library script(s) in 320usr/20sys/344real
> ms.^M
> wait results: 15196 exp6 0 1
> FAIL: LOCAL1 (0)
> starting stap -vu -p2 -e {
>     probe kernel.function("sys_getrlimit") { rlim_cur = $rlim->rlim_cud; }
> }

This and some of the others here are victims of SYSCALL_WRAPPERS
changes. I have a patch (yet to be checked in) for this. See bz10007.
Can you please try with the patch at:
http://sources.redhat.com/bugzilla/attachment.cgi?id=3896&action=view

Ananth

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Ananth N Mavinakayanahalli]

On Mon, Apr 27, 2009 at 04:42:50PM +0200, Mark Wielaard wrote:
> Hi Pavan,
> 
> On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote:
> > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
> > Arch: ppc64
> >
> > Please contact me, for any other details.
> 
> Thanks for testing this combination. Which elfutils version did you use?
> 
> > Unexpected failures
> > =============================
> > FAIL: LOCAL1 (0)

I've seen the above fail with LOCAL1 (2), which actually needs to be
flagged as a success. I guess the issue is with checking of rc -- down
in alternatives.exp:

- if {$rc == 1} { pass $test } else { fail "$test ($rc)" }
+ if {$rc >= 1} { pass $test } else { fail "$test ($rc)" }

should fix the problem.

Ananth

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Mark Wielaard]

On Tue, 2009-04-28 at 12:26 +0530, Ananth N Mavinakayanahalli wrote:
> On Mon, Apr 27, 2009 at 04:42:50PM +0200, Mark Wielaard wrote:
> > On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote:
> > > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
> > > Arch: ppc64
> > >
> > > FAIL: LOCAL1 (0)
> 
> I've seen the above fail with LOCAL1 (2), which actually needs to be
> flagged as a success. I guess the issue is with checking of rc -- down
> in alternatives.exp:
> 
> - if {$rc == 1} { pass $test } else { fail "$test ($rc)" }
> + if {$rc >= 1} { pass $test } else { fail "$test ($rc)" }
> 
> should fix the problem.

Yes, that seems fine. The LOCAL1 (0) failure case is as you observed
because of the syscall wrappers issue (I am thinking about the patch you
proposed in PR10007 and testing it locally - x86_64 only for now
though).

Cheers,

Mark

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Ananth N Mavinakayanahalli]

On Wed, Apr 29, 2009 at 10:57:01AM +0200, Mark Wielaard wrote:
> On Tue, 2009-04-28 at 12:26 +0530, Ananth N Mavinakayanahalli wrote:
> > On Mon, Apr 27, 2009 at 04:42:50PM +0200, Mark Wielaard wrote:
> > > On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote:
> > > > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
> > > > Arch: ppc64
> > > >
> > > > FAIL: LOCAL1 (0)
> > 
> > I've seen the above fail with LOCAL1 (2), which actually needs to be
> > flagged as a success. I guess the issue is with checking of rc -- down
> > in alternatives.exp:
> > 
> > - if {$rc == 1} { pass $test } else { fail "$test ($rc)" }
> > + if {$rc >= 1} { pass $test } else { fail "$test ($rc)" }
> > 
> > should fix the problem.
> 
> Yes, that seems fine. The LOCAL1 (0) failure case is as you observed
> because of the syscall wrappers issue (I am thinking about the patch you
> proposed in PR10007 and testing it locally - x86_64 only for now
> though).

Thanks Mark. I've attached an updated version just now.

Ananth

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Mark Wielaard]

On Tue, 2009-04-28 at 11:30 +0530, Pavan Naregundi wrote:
> Running /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp ...
> executing: stap /home/pavan/systemtap/src/testsuite/systemtap.base/cast.stp
> -g
> FAIL: systemtap.base/cast.stp
> line 4: expected "tv_sec OK"
> Got "tv_sec 42 != 0"
> testcase /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp
> completed in 8 seconds

That is strange, maybe struct timeval is different on ppc64 from what we
expect in the @cast or get_timeval() in the script. Maybe Josh has a
hunch what is going on (he wrote the test originally).

Cheers,

Mark

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Mark Wielaard]

On Tue, 2009-04-28 at 11:30 +0530, Pavan Naregundi wrote:
> > > FAIL: compiling sdt.c ""
> > > FAIL: compiling sdt.c additional_flags=-std=gnu89
> > > FAIL: compiling sdt.c additional_flags=-ansi
> > > FAIL: compiling sdt.c additional_flags=-pedantic
> > > FAIL: compiling sdt.c additional_flags=-ansi additional_flags=-pedantic
> > > FAIL: compiling sdt.c additional_flags=-O2
> > > FAIL: compiling sdt.c additional_flags="-O3"
> > > FAIL: static_uprobes compiling C -g
> 
> Running /home/pavan/systemtap/src/testsuite/systemtap.base/sdt.exp ...
> Executing on host: gcc
> /home/pavan/systemtap/src/testsuite/systemtap.base/sdt.c  -g
> -I/home/pavan/systemtap/src/testsuite/../includes/sys -Wall -Wextra -Werror
> -lm   -o sdt.c.exe.0    (timeout = 300)
> /tmp/ccastHp6.s: Assembler messages:^M
> /tmp/ccastHp6.s:57: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:116: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:179: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:246: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:317: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:392: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:471: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:554: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:640: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:729: Error: junk at end of line: `0'^M
> compiler exited with status 1
> output is:
> /tmp/ccastHp6.s: Assembler messages:^M
> /tmp/ccastHp6.s:57: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:116: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:179: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:246: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:317: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:392: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:471: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:554: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:640: Error: junk at end of line: `0'^M
> /tmp/ccastHp6.s:729: Error: junk at end of line: `0'^M
> 
> FAIL: compiling sdt.c ""
> UNTESTED: sdt ""
> 
> >
> > That probably means the sdt.h header doesn't compile on ppc.
> > Could you see if testsuite/systemtap.log gives more hints about what is
> > wrong? What gcc version are you using?
> 
> gcc version 4.3.2 20081007 (Red Hat 4.3.2-6) (GCC)

Thanks, I think the new "nop 0" in sdt.h is wrong on ppc64
I don't have a ppc64 around, but maybe this will work (assuming these
tests did work before):

diff --git a/includes/sys/sdt.h b/includes/sys/sdt.h
index f89b736..8e87942 100644
--- a/includes/sys/sdt.h
+++ b/includes/sys/sdt.h
@@ -58,7 +58,7 @@
 #define STAP_UNINLINE_LABEL(label) \
   __extension__ static volatile long labelval  __attribute__ ((unused))
= (long) &&label
 
-#if defined(__x86_64__) || defined(__i386__)
+#if defined(__x86_64__) || defined(__i386__) || defined(__ppc64__)
 #define STAP_NOP "\tnop "
 #else
 #define STAP_NOP "\tnop 0 "

Cheers,

Mark

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Mark Wielaard]

Hi Ananth,

On Wed, 2009-04-29 at 14:56 +0530, Ananth N Mavinakayanahalli wrote:
> On Wed, Apr 29, 2009 at 10:57:01AM +0200, Mark Wielaard wrote:
> > 
> > Yes, that seems fine. The LOCAL1 (0) failure case is as you observed
> > because of the syscall wrappers issue (I am thinking about the patch you
> > proposed in PR10007 and testing it locally - x86_64 only for now
> > though).
> 
> Thanks Mark. I've attached an updated version just now.

So that patch does give some new failures for me (version 0.9.7/0.137
commit release-0.9.7-27-g9997403 + changes on 2.6.18-128.1.6.el5xen
x86_64):

attempting command  stap -p4 para-callgraph.stp kernel.function("*@fs/proc*.c") syscall.read
OUT semantic error: probe point mismatch at position 2 (alternatives: return): identifier 'syscall' at para-callgraph.stp:15:7 while resolving probe point syscall.read.call
        source: probe $2.call {
                      ^
Pass 2: analysis failed.  Try again with another '--vp 01' option.
child process exited abnormally
RC 1
FAIL: systemtap.examples/general/para-callgraph build

So the problem there is that the function probe can have a .call
attribute, but the syscall probe doesn't.

spawn1 stap -p4 /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp
semantic error: probe point mismatch at position 3 (alternatives:): identifier 'syscall' at /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp:3:7 while resolving probe point syscall.read.return.maxactive(3)
semantic error: probe point mismatch at position 3 (alternatives:): identifier 'syscall' at /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp:3:7 while resolving probe point syscall.read.return.maxactive(3)
        source: probe syscall.read.return.maxactive(3)

        source: probe syscall.read.return.maxactive(3)
                      ^

                      ^
semantic error: no probes found

semantic error: no probes found
Pass 2: analysis failed.  Try again with another '--vp 01' option.^M

Pass 2: analysis failed.  Try again with another '--vp 01' option.^M
wait results: 16579 exp33 0 1
FAIL: buildok/maxactive01.stp

Similar problem, but now that a function.return probe can have a
maxactive attribute, while a syscall.return probe cannot.

The rest does seem to PASS as before, but I am somewhat concerned that
the tests were originally designed to test function (.call/return)
probes, which are different from syscall (.return) probes. So are we
really still testing the correct things?

Cheers,

Mark

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Ananth N Mavinakayanahalli]

On Wed, Apr 29, 2009 at 02:08:23PM +0200, Mark Wielaard wrote:
> Hi Ananth,
> 
> On Wed, 2009-04-29 at 14:56 +0530, Ananth N Mavinakayanahalli wrote:
> > On Wed, Apr 29, 2009 at 10:57:01AM +0200, Mark Wielaard wrote:
> > > 
> > > Yes, that seems fine. The LOCAL1 (0) failure case is as you observed
> > > because of the syscall wrappers issue (I am thinking about the patch you
> > > proposed in PR10007 and testing it locally - x86_64 only for now
> > > though).
> > 
> > Thanks Mark. I've attached an updated version just now.
> 
> So that patch does give some new failures for me (version 0.9.7/0.137
> commit release-0.9.7-27-g9997403 + changes on 2.6.18-128.1.6.el5xen
> x86_64):
> 
> attempting command  stap -p4 para-callgraph.stp kernel.function("*@fs/proc*.c") syscall.read
> OUT semantic error: probe point mismatch at position 2 (alternatives: return): identifier 'syscall' at para-callgraph.stp:15:7 while resolving probe point syscall.read.call
>         source: probe $2.call {
>                       ^
> Pass 2: analysis failed.  Try again with another '--vp 01' option.
> child process exited abnormally
> RC 1
> FAIL: systemtap.examples/general/para-callgraph build
> 
> So the problem there is that the function probe can have a .call
> attribute, but the syscall probe doesn't.

Ugh yes :(

> spawn1 stap -p4 /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp
> semantic error: probe point mismatch at position 3 (alternatives:): identifier 'syscall' at /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp:3:7 while resolving probe point syscall.read.return.maxactive(3)
> semantic error: probe point mismatch at position 3 (alternatives:): identifier 'syscall' at /home/mark/src/systemtap/testsuite/buildok/maxactive01.stp:3:7 while resolving probe point syscall.read.return.maxactive(3)
>         source: probe syscall.read.return.maxactive(3)
> 
>         source: probe syscall.read.return.maxactive(3)
>                       ^
> 
>                       ^
> semantic error: no probes found
> 
> semantic error: no probes found
> Pass 2: analysis failed.  Try again with another '--vp 01' option.^M
> 
> Pass 2: analysis failed.  Try again with another '--vp 01' option.^M
> wait results: 16579 exp33 0 1
> FAIL: buildok/maxactive01.stp
> 
> Similar problem, but now that a function.return probe can have a
> maxactive attribute, while a syscall.return probe cannot.
> 
> The rest does seem to PASS as before, but I am somewhat concerned that
> the tests were originally designed to test function (.call/return)
> probes, which are different from syscall (.return) probes. So are we
> really still testing the correct things?

Maybe the choice of functions weren't correct in the first place? Why
don't we change this to say, vfs_read instead of sys_read?

Ananth

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Mark Wielaard]

Hi Ananth,

On Wed, 2009-04-29 at 17:51 +0530, Ananth N Mavinakayanahalli wrote:
> On Wed, Apr 29, 2009 at 02:08:23PM +0200, Mark Wielaard wrote:
> > The rest does seem to PASS as before, but I am somewhat concerned
> that
> > the tests were originally designed to test function (.call/return)
> > probes, which are different from syscall (.return) probes. So are we
> > really still testing the correct things?
> 
> Maybe the choice of functions weren't correct in the first place? Why
> don't we change this to say, vfs_read instead of sys_read?

That sounds like a good plan to me.

Cheers,

Mark

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[David Smith]

Mark Wielaard wrote:
> The rest does seem to PASS as before, but I am somewhat concerned that
> the tests were originally designed to test function (.call/return)
> probes, which are different from syscall (.return) probes. So are we
> really still testing the correct things?

I've had some of the same concerns.  Also, if we look ahead a bit, it is
possible the syscall tapset will start using tracepoint probes instead
of kprobes.  Then the tests really won't be testing the correct things.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2

[Josh Stone]

Mark Wielaard wrote:
> On Tue, 2009-04-28 at 11:30 +0530, Pavan Naregundi wrote:
>> Running /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp ...
>> executing: stap /home/pavan/systemtap/src/testsuite/systemtap.base/cast.stp
>> -g
>> FAIL: systemtap.base/cast.stp
>> line 4: expected "tv_sec OK"
>> Got "tv_sec 42 != 0"
>> testcase /home/pavan/systemtap/src/testsuite/systemtap.base/cast.exp
>> completed in 8 seconds
> 
> That is strange, maybe struct timeval is different on ppc64 from what we
> expect in the @cast or get_timeval() in the script. Maybe Josh has a
> hunch what is going on (he wrote the test originally).

The scenario where this would fail is a big-endian machine where the
size of "long tv_sec" is different between kernel and user mode.  AFAIK,
ppc64 is one such machine.

I would say that the @cast is working fine here -- it's just a bad
assumption on my part in writing the test.  I'll see if there's another
struct type I can use that will be more robust...

Josh