Support ASAN (-fsanitize=address) for xtensa target

[paulreimer]

Not sure what is involved, but I know that ASAN support on x86 is amazing for finding tricky bugs, and I'd love to run it on my ESP32 debug builds.

I'm not sure what is involved in adding it for a new target. The current state seems to be a compiler warning (after adding -fsanitize=address to CXXFLAGS):

warning: -fsanitize=address not supported for this target

[paulreimer]

@jcmvbkbc noted this caveat (and helpful link!)

Also compiling with ASAN results in higher memory requirements: according to https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm it requires 1/8 of used memory for its shadow map.

https://github.com/jcmvbkbc/crosstool-NG/issues/51#issuecomment-348718890

[jcmvbkbc]

So I've added dummy ASAN support to the xtensa gcc: 1ebcd8481b0762f2126c1478d66a1f4aee369798 It will appear in gcc-7.3 and gcc-8. Using it I was able to enable KASAN support for xtensa in the linux kernel (see https://github.com/jcmvbkbc/linux-xtensa/commits/xtensa-ssp-kasan for details). One thing that I've noticed with the instrumented code is that it needs at least 4 times more stack space. The kernel image size has grown almost 2x.

It looks like enabling libsanitizer doesn't make much sense for embedded target as this library is oriented to big OSes like linux, *BSD and windows. Instead the ESP can take the kernel approach, invoke gcc with options like -fsanitize=kernel-address -fasan-shadow-offset=<shadow-offset-address> --param asan-stack=1 --param asan-globals=1 --param asan-instrumentation-with-call-threshold=<call-threshold>, implement __asan_load* and __asan_store* hooks that do actual checking, implement replacements for dynamic memory allocation/freeing functions to mark available dynamic memory and implement replacements for mem* and str* functions that do buffer validation.