Changes between Version 2 and Version 3 of Developer/SmallProjects


Ignore:
Timestamp:
Mar 25, 2009, 6:12:42 AM (11 years ago)
Author:
JoelSherrill
Comment:

New

Legend:

Unmodified
Added
Removed
Modified
  • Developer/SmallProjects

    v2 v3  
    2727 *  Writing test code
    2828  *  There is a continual need for more test code.   We would like a timing test suite for the POSIX thread support that is comparable to the current Classic API timing test suite.  We expect this will eventually comprise about 50 different tests so could be tackled as a class project with the individual tests assigned to different people or groups.
     29= Investigate GCC Test Failures =
     30
     31
     32The many many tasks that comprise this project are a bit harder but there are lots of small individual cases.  If this isn't your strength, don't feel bad.  But if you want to learn about debugging when you know very little, this is your opportunity. GCC is a complex beast with 100K tests.  You are expected to understand everything, just figure out why something isn't working and maybe give a hint that will move it to resolution.
     33
     34The GCC C, C++, and Ada test suites are regularly run on multiple architectures using simulators.  All RTEMS tools tests reports are archived at [http://www.rtems.org/pipermail/rtems-tooltestresults/] as well as at [http://gcc.gnu.org/ml/gcc-testresults].  Pick the latest test result for your favourite target architecture and start looking at the failure cases. 
     35# Make sure there isn't a PR for it already.  If there is, update it to note the failure is still occurring.
     36# Check out the gcc-testing CVS modules from the RTEMS CVS repository and follow the instructions to build and run the tests yourself.
     37# Pick a test that fails and investigate it
     38## Some "scan assembler" tests fail because RTEMS tests are run on a particular BSP which uses specific CPU model compile options which may conflict with the CPU model the instructions would be generated on. 
     39## Others may core dump.  Try to get a stack backtrace in gdb.
     40## Check that the stack isn't blown or that it isn't using too much memory for the BSP.  It may be "expected to fail" on this BSP.
     41# In all cases, file a PR at [http://gcc.gnu.org/bugzilla] so your explanation is captured.
     42# If you can provide a patch, try.  Fixing test infrastructure issues is generally easier than fixing code generation problems.