On Fri, Apr 14, 2023 at 10:12:55AM -0700, Josh Poimboeuf wrote: > > * How to avoid/minimize the need to reverse-engineer control flow for things > > like ORC generation. > > > > On the arm64 side we're pretty averse to doing this to generate metadata for > > unwinding (and we might not need to), but there are things objtool does today > > that requires awareness of control-flow (e.g. forward-edge checks for noinstr > > safety). > > > > Hopefully without a flamewar about DWARF... > > If objtool is going to be doing control-flow anyway then it could just > validate DWARF/SFrame. Then everybody's happy? Right; so per another recent thread somewhere; you can't rely on DWARF/Sframe or any other compiler generated thing simply because it doesn't cover .S files and inline asm -- and this being a kernel, we've got quite a bit of that. At best it could use DWARF to help reconstruct code flow and then validate Sframe for the bits that got sframe. FWIW, manually annotated asm without validation is an utter fail -- x86 tried that and it never works. FWIW2, building with DWARF info on is significantly slower / bigger. > > * Better compiler support for noinstr and similar properties. > > > > For example, noinstr functions are currently all noinline, and we can't > > inline a noinstr function into a noinstr function, leading to a painful mix > > of noinstr and __always_inline. Having a mechanism to allow noinstr code to > > be inlined into other noinstr code would be nice. > > Can you elaborate? Why can't noinstr inline noinstr? (that's a > mouthful) > > Is it because of potential cloning caused by IPA optimizations? It is because noinstr includes an explicit noinline. This is to avoid the cmpiler from inlining noinstr functions in regular functions -- which for obvious raisins must never happen. The compiler does not take the whole __sectio() attribute as a strong enough clue for inlining boundaries.
