Re: [PATCH 1/2] [RFC] debugobjects: avoid gcc-16.0.1 section mismatch

["Arnd Bergmann" <arnd@arndb.de>]

On Sun, May 10, 2026, at 21:31, Thomas Gleixner wrote:
> On Tue, Feb 03 2026 at 17:23, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> gcc-16 has gained some more advanced inlining techniques that enable
>> it to inline the is_static_object() function pointer into a specialized
>> version of lookup_object_or_alloc:
>>
>> WARNING: modpost: vmlinux: section mismatch in reference: lookup_object_or_alloc.part.0+0x1ac (section: .text) -> is_static_object (section: .init.text)
>>
>> From what I can tell, the transformation is correct, as this
>> is only called when lookup_object_or_alloc() is called from
>> debug_objects_selftest(), which is also __init.
>
> So clearly the compiler is buggy. It creates an __init specific copy of
> lookup_object_or_alloc() and then fails to attribute it correctly.

I don't see what else the compiler is supposed to do, it has no idea what
__init means in the kernel, or what the rules are for calling between
that and normal functions. Putting a non-inlined lookup_object_or_alloc()
into a special section without an explicit attribute would clearly
be a bug.

>> I have not come up with a good workaround, so this simply marks
>> is_static_object() as not __init. Since there are currently only two
>> files where this happens, that may be an easy way out.
>
> That's a horrible hack and while it's only two files today, this sounds
> like the start of a whack a mole game.

After thousands of randconfig builds, I found exactly the two
instances from this series.

Since this only happens in a very specific case where a file
uses function pointers to local functions and gcc is able
to turn these into direct calls, I wouldn't expect this to
become a widespread problem. It's normal for new compiler
versions to run into some corner cases like this when inlining
decisions change.

>> If anyone has a better idea for how to deal with that, let me know!
>
> Mark the compiler broken and wait until GCC people get their act
> together.

I'll have to retest with the actual release compiler, maybe they
changed something again that makes it go away already, otherwise
there is probably a flag to tell gcc to skip that optimization pass.

       Arnd