The mudflap run time checker was removed in GCC 4.9 and it is superseded by Address Sanitizer. The mudflap options remain, but do nothing. This page applies only to earlier versions of GCC.
Mudflap Pointer Debugging
It is enabled by passing -fmudflap to the compiler. For front-ends that support it (C and very simple C++ programs), it instruments all risky pointer/array dereferencing operations, some standard library string/heap functions, and some other associated constructs with range/validity tests. Modules so instrumented should be immune to buffer overflows, invalid heap use, and some other classes of C/C++ programming errors. The instrumentation relies on a separate runtime library (libmudflap), which will be linked into a program if -fmudflap -lmudflap is given at link time. Run-time behavior of the instrumented program is controlled by the MUDFLAP_OPTIONS environment variable. You can get an actual list of its options by setting MUDFLAP_OPTIONS to -help and calling a mudflap compiled program. At the moment this gives the following output:
The mudflap code can be controlled by an environment variable: $ export MUDFLAP_OPTIONS='<options>' $ <mudflapped_program> where <options> is a space-separated list of any of the following options. Use `-no-OPTION' to disable options. -mode-nop mudflaps do nothing -mode-populate mudflaps populate object tree -mode-check mudflaps check for memory violations (active) -mode-violate mudflaps always cause violations (diagnostic) -viol-nop violations do not change program execution (active) -viol-abort violations cause a call to abort() -viol-segv violations are promoted to SIGSEGV signals -viol-gdb violations fork a gdb process attached to current program -trace-calls trace calls to mudflap runtime library -verbose-trace trace internal events within mudflap runtime library -collect-stats collect statistics on mudflap's operation -sigusr1-report print report upon SIGUSR1 -internal-checking perform more expensive internal checking -print-leaks print any memory leaks at program shutdown -check-initialization detect uninitialized object reads -verbose-violations print verbose messages when memory violations occur (active) -abbreviate abbreviate repetitive listings (active) -timestamps track object lifetime timestamps (active) -ignore-reads ignore read accesses - assume okay -wipe-stack wipe stack objects at unwind -wipe-heap wipe heap objects at free -heur-proc-map support /proc/self/map heuristics -heur-stack-bound enable a simple upper stack bound heuristic -heur-start-end support _start.._end heuristics -heur-stdlib register standard library data (argv, errno, stdin, ...) (active) -free-queue-length=N queue N deferred free() calls before performing them (4) -persistent-count=N keep a history of N unregistered regions (100) -crumple-zone=N surround allocations with crumple zones of N bytes (32) -lc-adapt=N adapt mask/shift parameters after N cache misses (1000003) -backtrace=N keep an N-level stack trace of each call context (4) -thread-stack=N override thread stacks allocation: N kB (0)
Multithreaded Programs
Use -fmudflapth instead of -fmudflap to compile and -fmudflapth -lmudflapth to link if your program is multi-threaded.
Ignoring Pointer Reads
Use -fmudflapir, in addition to -fmudflap or -fmudflapth, if instrumentation should ignore pointer reads. This produces less instrumentation (and therefore faster execution) and still provides some protection against outright memory corrupting writes, but allows erroneously read data to propagate within a program.
Known Shortcomings
In a mail between Frank Eigler and Chris Scott (see http://gcc.gnu.org/ml/gcc/2005-01/msg01655.html) it became clear that at the moment mudflap does not insert padding between data structures which makes it blind to some program mistakes.
Consider the following example:
int a[1024];
int b[1024];
[...]
int *i;
for (i = &b[0] ; i < &a[1024] ; i++)
*i = 0;
[...]Currently mudflap will not detect the passage from b to a because it only checks that each individual pointer dereference points to a valid object: which for each value of i in this particular case, it does. It does not track the fact that i was originally assigned from &b[0].
A straightforward improvement to mudflap would be to emit padding between adjacent static (or even auto) objects, and mark those regions as inaccessible. Then such simple iteration patterns would be caught.
mudflap does not currently work with DSOs, see [gccbug:24420].
mudflap produces copious spurious violations for most C++ programs (e.g. any program using std::vector): see [gccbug:19319].
Further Reading
See: http://gcc.fyxm.net/summit/2003/mudflap.pdf