Having confidience that the code works as expect would be a really
good thing for perfmon2. Currently, there has been a significant
developement on perform2 in the kernel, the user-space libraries, and
example programs demonstrating how to use it. Software packages such
as gdb and gcc have dejagnu test suites that check for previous
problems and check that the code functions as expected. There should
be similar testing available for perfmon2. These tests should be be
able to run unattended.
The perfmon2 kernel additions, shared libraries, and differences in
performance monitoring hardware make it a bit more difficult to use
some of the existing tools. Testing of user-space programs can catch
cases where the program crashes, but testing of the kernel may cause a
crash of the system and require reboot. Valgrind intercepts the
systemcalls to model the kernels actions on userspace and the
additional systemcalls for perfmon2 are not recognized by valgrind
(some patches developed to address this Valgrind issue). Some
programming tools such as cgov are not designed to work with shared
libraries. Finally, each processor implementation has its own
implentation of performance monitoring hardware, the testsuite need to
be designed to allow for the variations between processor performance
monitoring hardware.
Testing the Kernel code
Want to check the following in kernel:
-Exercise the various sections of perfmon kernel code
-Invalid arguments to system calls handled gracefully
-No problems with locks
Much of the kernel testing could probably be done as part of the
libpfm testing.
Testing the shared libraries, examples, and pfmon
Want to check the following in shared libraries:
-Exercise the various sections of library and example programs
-Invalid arguments to library handled gracefully
-Check for use of uninitialized memory access past array bounds
At OLS2006 the use of GCC's mudflap option on libpfm example code was
demonstrated and confirmed an array bounds problems found earlier in
libpfm. Patches for valgrind have also been created to handle the new
perfmon2 systemcalls this should allow checking for problems with
memory allocation. The main limitations of these tools is the code
cannot be statically linked because they replace some of the memory
allocation routines. Currently, the libpfm examples are statically
linked.
It would be nice if valgrind had stripped down instrumentation to do
code coverage. It would be easy to get code coverage of shared
libraries then. Some people have used cachegrind to do this, but this
has significant slowdown due to the additional overhead to track
memory references and simulate the cache. The following URL outlines
what is required to make a stripped down code coverage skin, but
doesn't address mapping the data back to source code:
wwwse.inf.tu-dresden.de/data/courses/ss06/SFT/exercise/13_slides.pdf
Probably want to have several additional rules in the libpfm and pfmon
make file to run the tests, e.g. "check", "check_syscall",
"check_library", and "check_examples".
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
