On Thu, Apr 23, 2026 at 05:19:25PM +0200, Peter Zijlstra wrote: > On Thu, Apr 23, 2026 at 08:16:08AM -0700, Josh Poimboeuf wrote: > > On Thu, Apr 23, 2026 at 10:47:58AM +0200, Peter Zijlstra wrote: > > > On Wed, Apr 22, 2026 at 09:04:13PM -0700, Josh Poimboeuf wrote: > > > > PREFIX_SYMBOLS has a !CFI dependency because the compiler already > > > > generates __cfi_ prefix symbols for kCFI builds, so objtool-generated > > > > __pfx_ symbols were considered redundant. > > > > > > > > However, the __cfi_ symbols only cover the 5-byte kCFI type hash. With > > > > FUNCTION_CALL_PADDING, there are also 11 bytes of NOP padding between > > > > the hash and the function entry which have no symbol to claim them. > > > > > > If you force the function alignment to 64 bytes, the prefix will also be > > > 64bytes, rather than the normal 16. > > > > Sorry, how do you get 64 here? > > DEBUG_FORCE_FUNCTION_ALIGNMENT_64B=y
Ok, so in that case it would be 5-byte cfi symbol and 59-byte NOP gap. Or a 64-byte pfx for the !CFI case. > > > > The NOPs can be rewritten with call depth tracking thunks at runtime. > > > > Without a symbol, unwinders and other tools that symbolize code > > > > locations misattribute those bytes. > > > > > > > > Remove the !CFI guard so objtool creates __pfx_ symbols for all > > > > CALL_PADDING configs, covering the full padding area regardless of > > > > whether there's also a __cfi_ symbol. > > > > > > Egads, that a ton of symbols :/ Does it not make sense to 'fix' up the > > > __cfi_ symbols to cover the whole prefix? > > > > Yeah, I suppose that would be better, via objtool I presume. > > Yup. -- Josh
