Re: [PATCH] tracing: ring-buffer: allowlist clang-generated symbols

[Nathan Chancellor <nathan@kernel.org>]

On Wed, Jul 15, 2026 at 09:38:21AM +0200, Arnd Bergmann wrote:
> On Tue, Jul 14, 2026, at 23:56, Steven Rostedt wrote:
> > On Wed, 17 Jun 2026 14:26:36 +0100 Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> >> On Tue, Jun 16, 2026 at 06:42:03PM +0200, Arnd Bergmann wrote:
> >> > From: Arnd Bergmann <arnd@arndb.de>
> >> > 
> >> > In randconfig build testing using clang-22, I came across two
> >> > sets of extra symbols in the ring buffer code that may get
> >> > inserted by the compiler:
> >> > 
> >> > Unexpected symbols in kernel/trace/simple_ring_buffer.o:
> >> >          U memset
> >> > 
> >> > Unexpected symbols in kernel/trace/simple_ring_buffer.o:
> >> >                  U llvm_gcda_emit_arcs
> >> >                  U llvm_gcda_emit_function
> >> >                  U llvm_gcda_end_file
> >> >                  U llvm_gcda_start_file
> >> >                  U llvm_gcda_summary_info
> >> >                  U llvm_gcov_init
> >> > 
> >> > Add all of these to the allowlist.
> >> > 
> >> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> > ---
> >> >  kernel/trace/Makefile | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> > 
> >> > diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
> >> > index f934ff586bd4..aa8564fb8ff4 100644
> >> > --- a/kernel/trace/Makefile
> >> > +++ b/kernel/trace/Makefile
> >> > @@ -146,6 +146,7 @@ KASAN_SANITIZE_undefsyms_base.o := y  
> >> 
> >> Would "GCOV_PROFILE_undefsyms_base.o := y" work?
> >
> > Arnd?
> 
> Yes, turning off gcov for this file should avoid the llvm_gcda and
> llvm_gcov symbols, but not the memset() symbol.

This would actually turn on GCOV for this translation unit and cause the
llvm_gcda and llvm_gcov symbols to be included in UNDEFINED_ALLOWLIST
via the $(NM) call.

> All the other features that leave annotations are handled by
> listing the symbol names (__asan __gcov __kasan __kcsan __hwasan
> __sancov __sanitizer __tsan __ubsan __msan), so I think for
> consistency it makes sense to treat llvm gcov the same way
> we handle gcc gcov and the rest.

I do tend to agree with this though, as opposed to using
GCOV_PROFILE_... or ..._SANTIZE variables.

-- 
Cheers,
Nathan