Hi, Jim -
> A customer expressed interest in mudflap, so I tried to see if I > could use it compile something large. [...] Thanks for giving it a try. For what it's worth, I've run entire gcc bootstraps on Linux with the instrumentation running (using BOOT_CFLAGS rather than CFLAGS). Each time, it seems to take some tweaks in libmudflap or tree-mudflap to work again (pass cleanly). This indicates that there is a source of regressions that is not represented in the test suite. Regarding -fmudflap => -lmudflap, it used to do that. The problem was that the simplest use of specs machinery creates a final sequence of "-lFOO" options that sometimes cannot work. libmudflap must be in a particular spot on the command line so it can intercept calls into libc and other libraries, and from libgcc. Adding -lmudflap once to the beginning or end of all the libraries/objects is not sufficient IIRC. Regarding registering fopen return values, indeed libmudflap needs autoconf assistance. The issue is that on some libc implementations, fopen runs malloc to allocate the FILE, which we can sometimes intercept in libmudflap. Other implementations call private routines that we cannot intercept, so must register fopen return values manually. Regarding mmap/malloc recursion, this is similar to the fopen situation. Some reentrancy is expected; some is tolerated and prevented. You should not have to invent any further static counters for this stuff: the __mf_state variable should be able to do the right thing. Regarding error reports containing good application-level PCs, you're right that using builtin_return_address(0) is not sufficient for interior routines. Solutions would include snapshotting that value on a border function, hiding it in a per-thread global or widening the internal interfaces to pass it down. Regarding varargs, there is a libmudflap test case or two for that. The most problematic aspect seems to be ensuring that the variables being passed in varargs slots be registered with libmudflap, so va_arg() dereferencing is permitted. I recall at one point va_arg() being deliberately made uninstrumented, because doing the real registration work was too difficult. Either should at least shut libmudflap up. Regarding registration of static strings, this is one of the areas that seems to suffer from tree-ssa churn. tree-mudflap tries to arrange string constants and other static objects to be registered, but I recall tree flags switching interfering with this. In general the code is supposed to err on the side of registration. Regarding memory consumption, perhaps libmudflap's default backtrace parameter should be set to zero, for both speed and space reasons. Regarding the torrent of warnings/errors you encountered for the one or two actual bugs it found, yeah, it's not a great return. Once libmudflap is properly ported to *bsd, and the instrumentation-side regressions are fixed again, it will be much saner. - FChE
