How to develop and test code with gcc.
This is the very powerful command line debugger that comes with gcc. There are many quick start guides on the internet.
Like all command line debuggers, it can be intimidating to a new user. Some prefer a GUI interface to gdb such as ddd.
The code will sometimes terminate after tripping over an assert, or an other errors. To debug this in gdb, type "catch throw" when the debugger is started.
This checks for errors, memory leaks and file handles that are not closed at exit (the 3 standard handles stdin, stdout, and stderr are supposed to remain open at exit, but no others).
- What valgrind catches
- overruns for malloc'd arrays
- accessing uninitialized memory
- memory leaks
- file handles that are not closed
See the separate DevelopingWithValgrind page for further details.
gprof reports which routines consume the most time during a particular run. The build files for creating an executable suitable for profiling with gprof are located in source/sys_gcc_gprof. To use this do the following;
cd source/sys_gcc_gprof make -j 4 mkdir run cp ../../tsuite/auto/blr_fp89.in run cd run ../cloudy.exe < blr_fp89.in > blr_fp89.out gprof ../cloudy.exe > blr_fp89.prof
Running cloudy.exe creates the file gmon.out containing the performance statistics. This is then read with the gprof command: Add -l option to gprof to obtain line by line information.
Try to have nothing else running on the machine so that the timings are not disturbed.
Time profiling on a Mac
The build setup in sys_gcc_gprof should work. Apple provide their own version of gprof which does not behave like the gcc version. They recommend using Saturn (installed with xcode) to view the gmon.out performance statistics.
Source code coverage - gcov
This checks which lines of the source are tested during a run. We try to exercise all lines of source somewhere in the test suite. We certainly should exercise every command somewhere.
source / sys_gcc_gcov
has the makefiles to compile with gcov include. The exe is instrumented so running the code will do the coverage. Run gcov to extract information from the ancillary files created during a cloudy run.
to find out more. The runs are cumulative, so the coverage reported will include all runs in the test suite.
other array overrun checks
The Portland group compiler has an option to test for array bound overruns in declared C-style arrays. The makefile for this compiler is in source/sys_pgccBounds. That makefile also includes the -DBOUNDS_CHECK option described below on top of the compiler generated checks.
Cloudy versions C08 and later have the option to do array bounds checking. This is set with the command-line option -DBOUNDS_CHECK. This will enable bounds checking on all arrays derived from the multi_arr and flex_arr container classes, but none of the other arrays. It makes the code much slower, so should only be used for debugging and testing purposes.
Other compiler options
The Portland Group compiler is installed on cloud9. Some tests may fail with that compiler since it disables gradual underflow by default. gcc will disable gradual underflow if make is executed as follows:
make distclean make -j 4 EXTRA=-DFLUSH_DENORM_TO_ZERO
Return to DeveloperPages
Return to main wiki page