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.
