Am Samstag, dem 07.12.2024 um 17:58 -0800 schrieb Linus Torvalds: > On Sat, 7 Dec 2024 at 15:52, Martin Uecker <muecker@xxxxxxx> wrote: > > > > Can you point me to some horror stories? > > So the main issues tended to be about various static verification tools. > > Ranging from things like the stackleak plugin for gcc, where handling > VLA's and alloca() (which are pretty much the same thing with > different syntax) was just very much added complexity, to perhaps > overly simplistic tools that literally just check the stack usage by > parsing "objdump --disassemble" output and then building up > approximate "this is the combined deepest stack" call chain > approximations. > > And even in the *basic* infrastructure like gcc itself, VLA's simply > made -Wframe-larger-than= just simply not work. > > I also have this memory of bad code generation (again, this is 5= > years ago, so take this with a pinch of salt: dim memories), where gcc > wouldn't end up re-using VLA stack slots, so VLA's made the frame > bigger for that reason or something like that. > > We explicitly use "-fconserve-stack" to get gcc to reuse spill slots, > because gcc has been known to sometimes makes insanely piggish stack > frames when it just creates a spill slot for *everything*, even if the > spills aren't live at the same time (think big functions with lots of > case statements). > > We also had several cases of the VLA's just being silly, when a simple > constant-sized allocation just worked fine and didn't generate > pointless extra code. > > Pretty much none of the code core actually ever wanted VLA's, so the > end result was that we had these bad patterns mainly in random drivers > etc. Don't do that. Thanks. This confirms that the tooling around VLAs is rather poor. Martin
