https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:91b36d1c85ae3ad667d11c1ceeffc698126ab804 commit r13-5982-g91b36d1c85ae3ad667d11c1ceeffc698126ab804 Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Feb 14 12:10:09 2023 +0100 asan: Add --param=asan-kernel-mem-intrinsic-prefix= [PR108777] While in the -fsanitize=address case libasan overloads memcpy, memset, memmove and many other builtins, such that they are always instrumented, Linux kernel for -fsanitize=kernel-address recently changed or is changing, such that memcpy, memset and memmove actually aren't instrumented because they are often used also from no_sanitize ("kernel-address") functions and wants __{,hw,}asaN_{memcpy,memset,memmove} to be used instead for the instrumented calls. See e.g. the https://lkml.org/lkml/2023/2/9/1182 thread. Without appropriate support on the compiler side, that will mean any time a kernel-address instrumented function (most of them) calls memcpy/memset/memmove, they will not be instrumented and thus won't catch kernel bugs. Apparently clang 15 has a param for this. The following patch implements the same (except it is a usual GCC --param, not -mllvm argument) on the GCC side. I know this isn't a regression bugfix, but given that -fsanitize=kernel-address has a single project that uses it which badly wants this I think it would be worthwhile to make an exception and get this into GCC 13 rather than waiting another year, it won't affect non-kernel code, nor even the kernel unless the new parameter is used. 2023-02-14 Jakub Jelinek <ja...@redhat.com> PR sanitizer/108777 * params.opt (-param=asan-kernel-mem-intrinsic-prefix=): New param. * asan.h (asan_memfn_rtl): Declare. * asan.cc (asan_memfn_rtls): New variable. (asan_memfn_rtl): New function. * builtins.cc (expand_builtin): If param_asan_kernel_mem_intrinsic_prefix and function is kernel-{,hw}address sanitized, emit calls to __{,hw}asan_{memcpy,memmove,memset} rather than {memcpy,memmove,memset}. Use sanitize_flags_p (SANITIZE_ADDRESS) instead of flag_sanitize & SANITIZE_ADDRESS to check if asan_intercepted_p functions shouldn't be expanded inline. * gcc.dg/asan/pr108777-1.c: New test. * gcc.dg/asan/pr108777-2.c: New test. * gcc.dg/asan/pr108777-3.c: New test. * gcc.dg/asan/pr108777-4.c: New test. * gcc.dg/asan/pr108777-5.c: New test. * gcc.dg/asan/pr108777-6.c: New test. * gcc.dg/completion-3.c: Adjust expected multiline output.
