[Bug sanitizer/112644] [14 Regression] Some of the hwasan testcase fail after the recent merge

["tnfchris at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644

--- Comment #6 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Matthew has been working on this and so far has concluded:

Summary of main problem:

New libhwasan runtime libraries have added interceptors for various mem*, str*
functions (and I think others -- I do not have full list).

With old runtime libraries these were not intercepted, and we emitted inline
instrumentation to accommodate.
Removing our instrumentation is fine (though with the caveat that we need to
ensure we have the full list of functions which are now intercepted).

However, the libraries hard-code the choice to abort on error, which means the
HWASAN_OPTIONS environment variable can no longer be used to ensure recover on
error (-fsanitize-recover=hwaddress option).

Changes I believe should happen:
- LLVM upstream libsanitizer code be changed to allow recovery -- AFAIK there
is no functional loss from using ErrorAction::Recover in the checking.
- We find the list of functions which are now instrumented, and update
asan_instrumented_p accordingly (plus a testcase or two for this).

The first one was discussed on the LLVM discourse and it was deemed a bug
https://discourse.llvm.org/t/hwasan-question-about-the-recent-interceptors-being-added/75351/4
and a PR made to fix it https://github.com/llvm/llvm-project/pull/74000

Once that's merged we can re-sync and we need to update the list of intercepted
functions in asan_intercepted_p (in gcc/asan.h).  One of the reasons for the
change is that LLVM now replaces calls to e.g. memset with __hwasan_memset to
avoid later passes optimizing the call.  It looks like we need to do that for
GCC as well.

Matthew will be away for a while so will take over the patch from him in
stage-4.