On Tue, Jul 14, 2026, at 23:56, Steven Rostedt wrote:
> On Wed, 17 Jun 2026 14:26:36 +0100 Vincent Donnefort <[email protected]>
> wrote:
>
>> On Tue, Jun 16, 2026 at 06:42:03PM +0200, Arnd Bergmann wrote:
>> > From: Arnd Bergmann <[email protected]>
>> >
>> > 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 <[email protected]>
>> > ---
>> > 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.
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.
Arnd
