Re: [PATCH] serial: icom: Fix namespace collision and startup() section placement with -ffunction-sections

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Nov 19, 2025 at 07:58:05AM +0100, Jiri Slaby wrote:
> On 19. 11. 25, 7:27, Josh Poimboeuf wrote:
> > When compiling the kernel with -ffunction-sections (e.g., for LTO,
> > livepatch, dead code elimination, AutoFDO, or Propeller), the startup()
> > function gets compiled into the .text.startup section.  In some cases it
> > can even be cloned into .text.startup.constprop.0 or
> > .text.startup.isra.0.
> > 
> > However, the .text.startup and .text.startup.* section names are already
> > reserved for use by the compiler for __attribute__((constructor)) code.
> > 
> > This naming conflict causes the vmlinux linker script to wrongly place
> > startup() function code in .init.text, which gets freed during boot.
> 
> This sounds rather error-prone. What are the patterns supposed to match
> actually? Can't *those* real victims™ be renamed to something less common
> instead?

Yeah, this is a terrible mess. The problem is that when linking objects
build with and without -ffunction-sections you can no longer uniquely
identify what's what :-(

As long as its consistently one or the other it works, but if you mix
them constructors and normal function like this get mixed up.

In another thread I've suggested this might be a toolchain bug, but even
if they agree and fix it, we still stuck with the old compilers. And I'm
not sure the toolchain people are agreeing there's anything wrong here
-- the argument is that you shouldn't be mixing this or somesuch.

Anyway, objtool has a warning for this, so new occurrences should be
flagged before they get introduced. But yes, we need to make the tree
clean first.