Runtime security/memory checks for gcc/gdb

[Dotan Shavit]

You can also try:
gcc -fmudflap

#

On Monday 11 January 2010 23:54:09 Elazar Leibovich wrote:
> 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
>