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 :-(
