[77] in Software_Announce
gcc with bounds-checking available
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Jul 22 22:03:31 1995
Date: Sat, 22 Jul 1995 22:00:56 -0400
From: Greg Hudson <ghudson@MIT.EDU>
To: software-announce@MIT.EDU
Cc: developers@MIT.EDU, gnu@MIT.EDU
Richard Jones has recently developed bounds-checking patches for gcc.
These-checking patches check for sevearl kinds of memory-access
violations: reads from and writes to uninitialized memory, invalid
arguments to free(), and out-of-bounds array accesses.
I've built gcc 2.7.0 with these patches and installed them (pending
tonight's volume releases) in the gnu locker for Ultrix, Solaris,
NetBSD/i386, Linux, and IRIX (the bounds-checking patches don't work
properly with AIX right now; they're installed, but they'll fail if
you try to use them). gcc 2.6.3 is still the default version of gcc
in the gnu locker, so to enable bounds-checking, use the command "gcc
-V2.7.0 -fbounds-checking". Bug reports should go to gnu@mit.edu (or
to rj3@doc.ic.ac.uk if you're sure it's not a case of me screwing up
the installation).
There is one constraint you're likely to encounter while
bound-checking your code: signal handlers currently need to be
compiled as unchecked code. You can #include <unchecked.h> and
surround the signal handler code with "BOUNDS_CHECKING_OFF" and
"BOUNDS_CHECKING_ON" to do this. You can conditionalize on
__BOUNDS_CHECKING_ON to see if you're compiling with bounds-checking
support enabled.
Read the user manual if you want to use bounds-checking in a
multithreaded program. Also, you may want to look at the known bug
list in /mit/gnu/src/bounds-2.7.0-0.13/bounds/BUGS, since
bounds-checking support is not currently for the weak of heart.
Many of you are already familiar with Purify, so I'll include a brief
comparison: Purify is essentially seamless, is much easier to use, and
will help find memory leaks, file-descriptor leaks, and reads of
uninitialized memory in additon to the memory-access violations found
by gcc with bounds-checking patches. Purify will also handle C++
code, and will instrument libraries which have already been compiled
(bounds-checked gcc output will happily coexist with unchecked code,
but it won't find access violations there). On the other hand, the
gcc bounds-checking patches are free, largely platform-independent (at
the expense of being highly language-dependent), and will find
out-of-bounds array accesses that Purify won't find. Finally, Purify
won't even begin to work on a multithreaded program, while gcc with
bounds-checking has hooks for it.
One final note: if you read
/mit/gnu/src/bounds-2.7.0-0.13/bounds/INSTALL it will tell you that
you need to include <fix-args.h> after <srdarg.h> or <varargs.h>.
I've modified the gcc header files so this isn't necessary, so signal
handlers are all you need to worry about in single-threaded programs.
