CIS 542 Embedded Systems Programming – Summer 2013 Lecture ...

A tool you can use to measure coverage is called “gcov”. To use gcov, run the following:
gcc -fprofile-arcs -ftest-coverage myprog.c -o myprog
./myprog (this creates myprog.gcda/data and myprog.gcno/graph)
gcov myprog.c (this creates myprog.c.gcov)
gcov -b myprog.c will also give branch coverage info
Verification
Testing is nice and easy but, as has been famously pointed out, “testing can only prove the existence of
bugs, not their absence.” This is because, when we test, we pick representative inputs but we don't
choose all possible inputs and/or all possible behaviors.
It would be better to actually prove certain properties of the code. This is known as verification. In the
systems we're interested in here, these are often referred to as safety properties: we want to be able to
prove that there are certain bad things that can never happen.
For instance, in this case we may want to prove that the speed is always less than or equal to 100. This
can be done using a technique called model checking: we want to show that our code adheres to this
“model of correctness”.
Here is a piece of code that would use our control method:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
drive_car() {
}
int speed;
enum states state;
while (1) { // keep looping and waiting for signal
}
// assume this is our interface with the hardware
int signal = get_signal_from_driver();
enum events event;
if (signal == 0) event = brake;
else if (signal == 1) event = accel;
else continue; // illegal signal
speed = control(speed, event, &state);
To prove that the speed is always less than equal to 100, we can use a tool called BLAST. When using
this tool, we attempt to show that the property can never be violated: that is, that it is impossible for the
speed to go over 100.
Here is an updated version of the code that could be used with BLAST: