Runtime security/memory checks for gcc/gdb

[Orna Agmon Ben-Yehuda]

2010/1/12 Elazar Leibovich <elazarl at gmail.com>:
>
> On Tue, Jan 12, 2010 at 8:02 AM, Shachar Shemesh <shachar at shemesh.biz>
> wrote:
>>
>> Elazar Leibovich wrote:
>>
>> I tried using valgrind in a different project. The main problems I've had
>> with valgrind are speed
>>
>> Yes, that is known.
>>
>> and false positives.
>>
>> That one is new to me. Can you elaborate?
>
> IIRC the problem was using a different library, and tracing which problems
> are yours and which are of the library.
> See for instance this
> rant http://www.mega-nerd.com/erikd/Blog/CodeHacking/house_of_cards.html
> I haven't really got into this, so maybe the suprresion files does allow you
> to quickly fix it.
>>

Suppressions are exactly for this. And since valgrind has the option
to write suppression file excerpts, it is very convenient. However,
you should be careful about those, as you may be tempted to suppress
errors which seem to come from the library (I often have to suppress
compiler-library bugs), but are actually your own bugs, manifested in
a line inside the library.

I missed the system that you do use, but if you are using powerPC with
Linux or AIX, there are strong free-as-in-beer tools from IBM (
http://haifux.org/lectures/199/, the slides contain a summary of
several FOSS tools, too ). On Alpha there is the third tool which is
very strong.

>> Getting gdb to report that during runtime has its advantages.
>> Anyhow, I was hoping to hear about products/valgrind add-ons etc I do not
>> know.
>> The main practical problem with it, is convincing management that getting
>> a linux box or VM and build the code on it is worth our while...
>>
>> Personally, I think that you should start with gcc. Just because it spews
>> out thousands of warnings does not mean they are not all relevant. Compiler
>> warnings are the easiest to fix, easiest to find, and are often written off
>> for no justifiable reason.
>
> It's more complex than that. The code currently work on the embedded device.
> This is a mission critical device, so we cannot make changes to the runtime
> code without testing it throughly first.
> I try therefor to fix the problem in the emulation level without touching
> the actual code. (for instance, overriding a certain problematic function
> which used an uninitialized variable, and got away with it in the embedded
> device, but not in the desktop, or, replace the macro which stores a
> specific memory address (hex number) which is used by a the code, and is
> obviously relevant only for the embedded device)
> Having a good runtime error checks (such as valgrind) will help me with
> recognizing this anomalities.
>>
>> I'm not sure at which version this started, but gcc 4.4.2 with -Wextra
>> catches your second example (array bounds problem).
>
> That surprising, more complex instances could be reducable to the halting
> problem (number of times we advance p might depend on any complex function).
> Didn't work for me. (Does it check that during runtime? perhaps it doesn't
> work with mingw).
> Leibo at Leibo-PC ~
> $ cat tmp.c
> int main(int argc,char **argv) {
>     int x[10],y[10],i=0;
>     int *p = x;
>     for (;i<=13;i++,p++) *p = (*p)++;
>     return 0;
> }
> Leibo at Leibo-PC ~
> $ /cygdrive/c/MinGW/bin/gcc.exe --version
> gcc.exe (TDM-2 mingw32) 4.4.1
> Copyright (C) 2009 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Leibo at Leibo-PC ~
> $ /cygdrive/c/MinGW/bin/gcc.exe -Wextra -Wall tmp.c
> tmp.c: In function 'main':
> tmp.c:2: warning: unused variable 'y'
> tmp.c:1: warning: unused parameter 'argc'
> tmp.c:1: warning: unused parameter 'argv'
>>
>> Shachar
>>
>> --
>> Shachar Shemesh
>> Lingnu Open Source Consulting Ltd.
>> http://www.lingnu.com
>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>