Runtime security/memory checks for gcc/gdb

[Elazar Leibovich]

We have a big legacy embedded code we need to maintain. Often, we wish to
run some functions of the code on the PC with injected input, to test them
or to test changes we've done to them without loading the code to the device
it should run on.
The code is written with C.
Obviously, this is not an easy task, it is more difficult because, the code
is bug ridden, and many times it works by accident (for example, a NULL
pointer added a constant and then derefeced, this worked because the memory
address was legal).
Since the code is big, our strategy is: compile just the parts you need,
debug it enough so that it would run on the PC, and keep the changes.
Hopefully, after enough time, all (or most) of the code would be runnable on
a PC.
We use gcc+gdb to compile and debug the code. In Visual Studio's
cl.exe there are some security
checks<http://msdn.microsoft.com/en-us/library/aa289171(VS.71).aspx>at
run time. This can really assist debugging. For example knowing when
an
unintialized variable was used can save you alot of frustration when trying
to figure out why you're getting a wrong numberic results.
My questions are:
1) Are there parallel (or better) runtime security checks for gcc/gdb? I
found the -fstack-protection stack canary switch, but are there more of this
type?
2) What other tools are there which offer similar protection? Valgrind of
course is the first thing that comes to my mind, but I'll be glad to hear
any more ideas.
For example, I would love to be able to get a warning whenever a pointer is
dereferenced twice, where the first time the pointer points at the memory
address of variable x, and the second time it points to variable y. That way
I'll get a warning for the following bug:
int x[3] = {1,2,3};int y[3] = {4,5,6};
int *p = x;
for (int i=0;i<=3;i++,p++) (*p) = (*p)++; // note the <=
3) We use win32 for regular development, so if anyone knows what is the
support for such tests in cygwin/mingw, I'll be glad to hear about it.

Thanks
Elazar Leibovich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20100111/46658cc5/attachment-0001.html>