trace/simple_ring_buffer build failure on parisc, sparc64

trace/simple_ring_buffer build failure on parisc, sparc64

[Guenter Roeck]

Hi,

when trying to build parisc:allmodconfig or sparc64:allmodconfig,
I get the following errors.

Building parisc:allmodconfig ... failed
--------------
Error log:
Unexpected symbols in kernel/trace/simple_ring_buffer.o:
         U __atomic_hash
         U trace_hardirqs_off
         U trace_hardirqs_on
         U warn_bogus_irq_restore

Building sparc64:allmodconfig ... failed
--------------
Error log:
Unexpected symbols in kernel/trace/simple_ring_buffer.o:
                 U 
                 U 
                 U current_thread_info_reg

I always thought this has to do with my environment and/or C compiler, but
it seems as if the problem appears to be generic.

I have no idea what causes the problem, why only those architectures are
affected, or how to fix it. If anyone has an idea, please let me know and
I'll be happy to write a patch and/or test it.

I disabled CONFIG_RING_BUFFER for test builds of parisc and sparc64 for
now, so this does not directly affect my test builds anymore. This is
primarily a report that the problem exists, not a request to fix it.

Thanks,
Guenter

Re: trace/simple_ring_buffer build failure on parisc, sparc64

[Vincent Donnefort]

On Tue, Sep 22, 2026 at 08:57:05AM -0700, Guenter Roeck wrote:
> Hi,
> 
> when trying to build parisc:allmodconfig or sparc64:allmodconfig,
> I get the following errors.
> 
> Building parisc:allmodconfig ... failed
> --------------
> Error log:
> Unexpected symbols in kernel/trace/simple_ring_buffer.o:
>          U __atomic_hash
>          U trace_hardirqs_off
>          U trace_hardirqs_on
>          U warn_bogus_irq_restore
> 
> Building sparc64:allmodconfig ... failed
> --------------
> Error log:
> Unexpected symbols in kernel/trace/simple_ring_buffer.o:
>                  U 
>                  U 
>                  U current_thread_info_reg

Thanks for the report. I could reproduce with clang. I should have a fix
shortly.

> 
> I always thought this has to do with my environment and/or C compiler, but
> it seems as if the problem appears to be generic.
> 
> I have no idea what causes the problem, why only those architectures are
> affected, or how to fix it. If anyone has an idea, please let me know and
> I'll be happy to write a patch and/or test it.
> 
> I disabled CONFIG_RING_BUFFER for test builds of parisc and sparc64 for
> now, so this does not directly affect my test builds anymore. This is
> primarily a report that the problem exists, not a request to fix it.
> 
> Thanks,
> Guenter

-- 
Vincent

Re: trace/simple_ring_buffer build failure on parisc, sparc64

[Vincent Donnefort]

On Wed, Sep 23, 2026 at 08:19:08AM +0100, Vincent Donnefort wrote:
> On Tue, Sep 22, 2026 at 08:57:05AM -0700, Guenter Roeck wrote:
> > Hi,
> > 
> > when trying to build parisc:allmodconfig or sparc64:allmodconfig,
> > I get the following errors.
> > 
> > Building parisc:allmodconfig ... failed
> > --------------
> > Error log:
> > Unexpected symbols in kernel/trace/simple_ring_buffer.o:
> >          U __atomic_hash
> >          U trace_hardirqs_off
> >          U trace_hardirqs_on
> >          U warn_bogus_irq_restore
> > 
> > Building sparc64:allmodconfig ... failed
> > --------------
> > Error log:
> > Unexpected symbols in kernel/trace/simple_ring_buffer.o:
> >                  U 
> >                  U 
> >                  U current_thread_info_reg
> 
> Thanks for the report. I could reproduce with clang. I should have a fix
> shortly.
> 
> > 
> > I always thought this has to do with my environment and/or C compiler, but
> > it seems as if the problem appears to be generic.
> > 
> > I have no idea what causes the problem, why only those architectures are
> > affected, or how to fix it. If anyone has an idea, please let me know and
> > I'll be happy to write a patch and/or test it.
> > 
> > I disabled CONFIG_RING_BUFFER for test builds of parisc and sparc64 for
> > now, so this does not directly affect my test builds anymore. This is
> > primarily a report that the problem exists, not a request to fix it.
> > 
> > Thanks,
> > Guenter
> 
> -- 
> Vincent

https://lore.kernel.org/linux-trace-kernel/20260923074213.3077182-1-vdonnefort@google.com/T/#t

Is that good enough?

-- 
Vincent