Plumhall automated testing

From Dmz-portal

Jump to: navigation, search

Contents

Plumhall C test suite

Plumhall C test suite is now in the automated testing. The results log the fulltest.sum file and the list of skipped or failed tests. Changes to the test suite should be done in the Plumhall repository. Due to the licensing constraints of Plumhall, this repository is only accessible to MIPS employees in the office. Please limit changes to flags.h, envsuite, and scripts in the scripts directory.

Process automated testing uses to run Plumhall

The automated testing builds LLVM and runs various test suites including Plumhall. This process assumes you have a previously built version of LLVM which the automated test process will have already built. Also, this builds Plumhall using little endian, PIC code and the GCC assembler. You'll need to change the parameters passed to the run-plumhall script and the QEMU variables if this is not how you're running Plumhall.

 base_dir=$(pwd)
 export CLANG_ALT_DRIVER="$base_dir/clang-alt-driver/src/mips_linux_gnu_gcc"
 export PLUMHALL_SRC="$base_dir/plumhall/cvs10a_full/cvs10a"
 export PLUMHALL_DST="$base_dir/plumhall-results"
 export QEMU="/mips/tools/mips/swpkgs/bin/run-on-qemu"
 export QEMUFLAGS="-p -EL"
 git clone -b master git://dmz-portal.mips.com/plumhall.git
 git clone -b master git://dmz-portal.mips.com/llvm_driver.git clang-alt-driver
 ./clang-alt-driver/src/DriverConfig.py -l /path/to/LLVM/build/Debug+Asserts/directory/or/the/install/directory -g /mips/arch/overflow/codesourcery/mips-linux-gnu/pro/release/2011.03-95/Linux
 plumhall/scripts/run-plumhall '-mips32r2 -fPIC -EL'

Updating flags.h

The flags.h file in Plumhall controls which tests are run and which are skipped. A bug should be created in Bugzilla for any tests that are skipped in Plumhall. When the test starts to work, then the skip flag should be removed from Plumhall and the Bug closed. The flags.h file is a C header file. Comments are C style comments. Tests are skipped by using #define and the correct define.

Skipping a test:

  1. Create a new bug in Bugzilla for the test being skipped
  2. Checkout the Plumhall repository
  3. Edit the plumhall/plumhall/cvs10a_full/cvs10a/dst.mips/flags.h file
  4. Find the SKIP #define for the test in the flags.h file and uncomment it if found. It may be in the file more than once.
  5. If it isn't in the file, add a #define for it at the bottom of the flags.h file with the other skipped tests.
  6. Add a comment with a link to the Bugzilla bug number
  7. Save the flags.h file
  8. Commit the change to the Plumhall repository
  9. Push the Plumhall repository back to the server

Plumhall debugging rules

The contract allows us to send parts of the plum hall test suite to outside contractors with the following rules:

  1. The whole driver can be sent out. In other words, what is in the dst part of it.
  2. Single test files can be sent and debugged. After resolving the issues, the test files should be deleted.

When a test fails, there are these self contained files that are created by the suite. These single files usually should be all you need.

Generally, send only what is needed to recreate that particular problem.

Be careful with this because the tests are watermarked. That is, each customer that has plum hall gets a slightly different version of it so that each copy can be uniquely identified.

That is, if the source gets out , Plum Hall can possibly figure out that it was our copy.

If a bug needs to be submitted to clang, then a new test needs to be made creatively that does not look at all like the original but causes the bug to happen too.

If this can't be done for some reason or it's too much work, it's possible to file a clang bug and just reference the plum hall test that fails.

Apple has some version of plum hall but does not run it anymore.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox