Re: testsuite status

[Roland McGrath <roland at redhat dot com>]

> There's something wrong with your build.  On my
> 2.6.34-0.49.rc7.git0.fc14.x86_64 rawhide vm, I only get 1 unexpected
> failure from the 'buildok' testsuite, where they almost all failed for you.

Mine is F-13, not rawhide.  I did a 'make clean' and re-build and got the same.

.../configure --disable-refdocs --disable-docs CFLAGS=-g CXXFLAGS=-g

elfutils-0.147-1.fc13.x86_64
gcc-4.4.4-2.fc13.x86_64
binutils-2.20.51.0.2-20.fc13.x86_64
kernel-2.6.33.3-85.fc13.x86_64
kernel-debuginfo-2.6.33.3-85.fc13.x86_64

> Try something simple like:
> 
> # stap -vp4 -e 'probe begin { printf("hello world\n") }'
> 
> Then try something harder like:
> 
> # stap -vp4 -e 'probe syscall.read { printf("read %d bytes\n", count) }'

Both these complete fine with ./run-stap in my build.

> Hmm, not that I know of.  You might be able to:
> 
> - delete your cache directory (in the testsuite, not in your home dir)
> - run the original code, then move the cache directory someplace
> - compile your new code, run the testsuite
> - compare old and new cache directories

Sounds automatable.

> The hard part here might be mapping a cached C file back to its original
> script.

I don't actually care all that much about that, since I'm just going to
look at the diffs and go back to the translator code that generates C code
that looks like that.  But, maybe the testsuite could use -m options with a
name derived from the testsuite source file name or test description, and
use cache file names with that (instead of _$pid) in the name?

Or, could have .systemtap/cache/xx/stap_xxyyzz.log stored with original
command line and file names, some bits of -v-like output, etc.  That is
probably worthwhile by default, just so you can always go and see a little
bit of paper trail when there is a cached .c or .ko around and something
needs investigation.


Thanks,
Roland