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
