Question

mipsel-linux-gcc -fsanitize=leak -g leak.c -o memleak
/usr/local/mips/mipsel-buildroot-linux-gnu/bin/../lib/gcc/mipsel-buildroot-linux-gnu/10.3.0/../../../../mipsel-buildroot-linux-gnu/bin/ld: cannot find liblsan_preinit.o: No such file or directory
/usr/local/mips/mipsel-buildroot-linux-gnu/bin/../lib/gcc/mipsel-buildroot-linux-gnu/10.3.0/../../../../mipsel-buildroot-linux-gnu/bin/ld: cannot find -llsan
collect2: error: ld returned 1 exit status

Answer

No support for mips32 or other 32bit machine, here is the information I got:

https://github.com/google/sanitizers/issues/294

Am I understanding right that this is 32-bit ARM? If so, have you tested this patch on any sufficiently big app?

The problem with 32-bit architectures is that a random 32-bit number is very likely to be treated as a pointer to some existing allocation. This may lead to false negatives in leak detection. In fact that’s why there’s no 32-bit x86 LSan.

using 32-bit leak detector becomes painful after some period of deployment, as we’ve learned in a hard way. The major trouble is that the leak detector has lots of flaky false negatives (missed leaks) https://code.google.com/p/valgrind-variant/wiki/LeakCheckingOn32bits

If you have a choice to use AArch64 instead of ARM for leak detection, go for it. If no, then, well, we’ve warned you. :)

Hm, you are actually right - LSan on ARM only finds about 15% of leaks. The results are close to valgrind’s on x86 so we decided to halt our work.

https://github.com/google/sanitizers/issues/403

This has come up before, including the bug you mentioned above, and it is problematic for the reasons you mostly explained. :)
We are deliberately not enabling lsan on 32-bit – it will have too high maintenance cost for us and we are not willing to pay it, sorry.

If you are still enthusiastic, keep updating this bug with more details/patches, maybe someone else will find them useful.

https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20141006/238475.html

Thanks for working on this. We are unlikely to accept patches that enable LSan on 32-bit architectures. Experiments on x86 and ARM have shown that the smaller address space makes leak detection very unreliable, to the point where it’s difficult to even test the tool. See e.g. the discussion at https://code.google.com/p/address-sanitizer/issues/detail?id=294

https://lists.llvm.org/pipermail/llvm-commits/Week-of-M

32-bit MSan is theoretically possible, but due to the size of the shadow mapping it may be challenging to find a working memory layout. You would also end up with very low available memory for the application.

http://reviews.llvm.org/D5616

https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20141006/239001.html

msan and especially tsan are very hard on 32-bit. Please do not even attempt 32-bit MIPS tsan/msan before making them work on 64-bit MIPS (should be easy) and on 32-bit x86 (hard, complex, low value/priority, the resulting tool will be very restricted).

asan on 32-bit MIPS is a different story – it should be easy.