Re: [PATCH 2/4] media: atomisp: Fix startup() section placement with -ffunction-sections

Re: [PATCH 2/4] media: atomisp: Fix startup() section placement with -ffunction-sections

[Peter Zijlstra]

On Wed, Nov 12, 2025 at 03:47:49PM -0800, 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.
> 

Urgh, that's a 'fun' one. Is this not a -ffunction-sections bug? I mean,
the compiler should never put regular non-reserved user symbols in a
section it has reserved for itself, right?

Re: [PATCH 2/4] media: atomisp: Fix startup() section placement with -ffunction-sections

[Josh Poimboeuf]

On Fri, Nov 14, 2025 at 09:56:57AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 12, 2025 at 03:47:49PM -0800, 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.
> > 
> 
> Urgh, that's a 'fun' one. Is this not a -ffunction-sections bug? I mean,
> the compiler should never put regular non-reserved user symbols in a
> section it has reserved for itself, right?

Right, so there's no ambiguity *IF* we know in advance whether it was
compiled with -ffunction-sections.  If so, constructor code goes in
.text.startup.*, and startup() goes in .text.startup or
.text.startup.constprop.0 or .text.startup.isra.0.

So it's not really a compiler bug because it's possible to disambiguate
those.

Problem is, we can have some objects compiled with -ffunction-sections,
and some compiled without, in the same kernel.  So the disambiguation
isn't possible at link time, since for example .text.startup could be
startup() with -ffunction-sections, or it could be
__attribute__((constructor)) without -ffunction-sections.

I attempted to describe all that in patch 4.

-- 
Josh

Re: [PATCH 2/4] media: atomisp: Fix startup() section placement with -ffunction-sections

[Peter Zijlstra]

On Fri, Nov 14, 2025 at 12:43:10PM -0800, Josh Poimboeuf wrote:
> On Fri, Nov 14, 2025 at 09:56:57AM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 12, 2025 at 03:47:49PM -0800, 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.
> > > 
> > 
> > Urgh, that's a 'fun' one. Is this not a -ffunction-sections bug? I mean,
> > the compiler should never put regular non-reserved user symbols in a
> > section it has reserved for itself, right?
> 
> Right, so there's no ambiguity *IF* we know in advance whether it was
> compiled with -ffunction-sections.  If so, constructor code goes in
> .text.startup.*, and startup() goes in .text.startup or
> .text.startup.constprop.0 or .text.startup.isra.0.
> 
> So it's not really a compiler bug because it's possible to disambiguate
> those.
> 
> Problem is, we can have some objects compiled with -ffunction-sections,
> and some compiled without, in the same kernel.  So the disambiguation
> isn't possible at link time, since for example .text.startup could be
> startup() with -ffunction-sections, or it could be
> __attribute__((constructor)) without -ffunction-sections.
> 
> I attempted to describe all that in patch 4.

Egads, what a mess :-(