GDB's test suite is capable of running on a great many architectures and target boards. Unfortunately, there are problems when attempting to run the test suite using a compiler other than GCC. While GDB and Dejagnu do their best to be vendor neutral, the simple truth is that they simply assume that all compilers act like GCC.
This page will attempt to explain how to run the test suite on a non-GCC compiler. Example configurations are given for running the test suite using ARM's RealView and Intel's ICC compilers. This is only a very gentle (and probably incomplete) introduction on how to do this. If you need to do this regularly, you will certainly need to invest more time figuring out how to obtain better results than you might get by following the instructions here. [And if you do, please edit this page!]
Dejagnu is the testing framework underneath GDB's test suite. It has a bewildering assortment of configuration options which allow it to run tests on any number of "boards." A board is simply a configuration; it is not necessarily literally a board. Configuration options include, amongst other things, the compiler to use to run tests. While it might seem like this is the simple, one-line answer to "how to run the test suite using another compiler," this page would not exist if it actually was so simple!
We want to define our own "board" to use a different compiler. How do we do this? The first step is to define our own site configuration file for Dejagnu, site.exp. Dejagnu reads this file at startup to allow you to customize test configurations. I'm simple, so I keep my site.exp very simple:
$ cat ~/site.exp global boards_dir lappend boards_dir /home/john.doe/boards
This tells Dejagnu to search the directory /home/john.doe/boards for additional board configuration files. This is where I store all of my custom testing configurations. You must also set your environment for it:
$ export DEJAGNU=~/site.exp
Configury for Intel's ICC
Intel's toolchain mimmicks GCC very well: it understands many of GCC's command-line options as-is, and it even contains compatibility modes for various flavors of GCC. It is therefore relatively trivial to get GDB's test suite to use it. Here is the best Dejagnu board configuration I've found:
$ cat ~/boards/icc.exp set_board_info compiler icc set_board_info c++compiler icpc set_board_info f77compiler ifort set_board_info multitop "" load_base_board_description "unix"
The configuration sets the C and C++ compilers to their Intel equivalents and disables multilibs. [If you do not explicitly quash multilibs, Dejagnu will attempt to run icc --print-multi-lib, which ICC does not understand.] It then loads the generic base board configuration for unix workstations. The trick here is to pre-define the "overrides" before loading the base board description. Dejagnu's set_board_info procedure will not overwrite any previously defined board property. [Although you could also call unset_board_info and then set the property, but that's twice as much typing, and I'm generally quite averse to superfluous typing.]
One also needs to initialize ICC to be able to run it normally. Replace intel64 by ia32 on 32bit hosts or to test cross-arch debugging:
$ source /opt/intel/Compiler/*/*/bin/iccvars.sh intel64
Believe it or not, that is all that is necessary. To run your GDB tests against ICC, simply tell Dejagnu to use the board "icc":
$ make check RUNTESTFLAGS="--target_board=icc"
When all is said and done (and tested), you will have a "testsuite.icc" directory containing your test suite results, which is very convenient if you run, for example, GCC and ICC tests using the same version of gdb. [Apparently you can specify some or all of these property overrides in RUNTESTFLAGS, but I have hardly played with this. If you know how, please update this page!]
Configury for RealView
Unlike Intel's compiler, ARM's RealView compiler is a bit trickier, since it does not have any sort of GCC compatibility mode. To compound matters, if you are attempting to run against a simulator (as I am here), we have just opened a can of configuration worms inside Dejagnu. Not the least of these problems is a relatively poor assumption that any output from the compiler constitutes a compile failure. If you are testing RealView using an evaluation version, none of your builds will appear to work because of the nice licensing warning that armcc outputs whenever you attempt to use it:
Warning: C9931W: Your license for Compiler (feature compiler) will expire in 18 days
Because this is an embedded platform, we run into additional problems with multilibis, linker flags (and libraries), assembly, running thumb code, etc. I've found that the easiest way to overcome the multitude of bad assumptions concerning the compiler is to wrap armcc with a script which translates GCC options into armcc options.
But first things first, let's take a look at the realview-sim board configuration which is going to tell Dejagnu how to run tests using the RealView compiler:
$ cat ~/boards/realview-sim.exp set_board_info multitop "" set_board_info mathlib "" set_board_info needs_status_wrapper 0 load_base_board_description "arm-sim"
This board configuration does not set the compiler for this board. This is because I am simply going to call my wrapper "arm-elf-gcc". If you wanted to call your wrapper something else (because you have the real arm-elf-gcc installed and in your PATH), you could set the compiler and c++compiler options to point to that script instead, just as we did for ICC above.
I've also disabled multilibs and linking against the math library. If you want to use either of these facilities, you have two options: 1) add appropriate bits to the board configuration or 2) modify the wrapper script to handle the appropriate options (and comment out/delete the two options from the board configuration).
The example wrapper script contains the necessary basics to do either of these, but you will have to fill in the proverbial blanks since I do not require them.
Before loading the defaults for an arm-based simulator (arm-elf-run, shipped with gdb), we override the simulator's status_wrapper property. To be honest, I do not know why this is necessary, but if you do not do this, Dejagnu will attempt to build a wrapper for the simulator (so that it will pass exit status to the shell), but it will use armcc to build it. Not exactly what you want when running the simulator on x86 linux! [Again if you know a better way, please update this page!]
As far as Dejagnu is concerned, we are done! All the real work goes into the wrapper script, which I've attached to this article. All in all, it is pretty self-explanatory. It ignores a lot of GCC-isms; it translates several others. It probably is missing a bunch more, but it seems to be enough for me to do some rudimentary GDB testing on the simulator with armcc. Again if you know something about how to make the wrapper better, please update it!