Tools that intercept functions -- as most of them do with malloc/free/etc -- don't work as well if the executable is statically linked, because then the intercepts don't work and the checking is done at the coarser mmap level. It would be nice if Valgrind could emit a warning about this at start-up. That way if people have control over the static linking, they can change it when using Valgrind. I'm not sure how to detect if an executable is statically linked, though. Perhaps there's something in the ELF/Mach/whatever headers. I'm also not sure if it's an issue on Mac OS X, as I think there's no such thing as a truly statically linked executable on Max OS X.
Here is a related discussion: http://thread.gmane.org/gmane.comp.debugging.valgrind.devel/8199 Very useful feature! I would add there there should be a way to convert this warning into error (memcheck and helgrind are absolutely useless for static binaries)
It's actually quite easy - a statically linked program won't have an interpreter so you just need to add something at the end of VG_(load_ELF) in coregrind/m_ume/elf.c to issue a warning (or set a flag to trigger a warning elsewhere) when interp is NULL. In fact the interpreter address is placed in ExeInfo as interp_base so you can use that as well, which is a bit more widely available.
In 3.8.0 SVN, there is a new option --soname-synonyms which allows to have statically linked malloc lib to be intercepted. This command line option however only works if special redirections have been used in the vgprelaod (and the vgpreload must of course still be preloaded). Currently, only the malloc lib redirections of V have been modified to use --soname-synonyms