> Hi, > > to those who are pushing the -fno-omit-frame-pointer change: Are you aware > that neither that flag nor even -mno-omit-leaf-frame-pointer actually > guarantee that every leaf function is going to carry a frame pointer, as > required for your backtraces? This feels slightly too aggressive relative to the significance of your example. What has happened is that because -O2 optimized away all of the stack access for the function, so it uses no space on the stack, so there is no stack frame separate from the caller's. It is unlikely that the critical bottleneck of any applications will be on such a function. And also, nobody including the proponents of this change are going to argue for disabling ALL of the optimizations which may possibly make the frame pointer not-perfect, including all inlining and tail call optimization. see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902 https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=8e941ae950ddce17 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018 https://developer.arm.com/documentation/dui0774/k/Compiler-Command-line-Options/-fomit-frame-pointer---fno-omit-frame-pointer "When there is no stack access, there is no need to use frame pointer even if -fno-omit-frame-pointer is used and caller's frame pointer is unchanged." "A function that does not use any stack space does not need to create a frame record, and leaves the frame pointer pointing to the caller's frame." > Frame pointers sound like a simple solution to unwinding, but they are not. > They are no complete replacement for unwinding information. > > Kevin Kofler I don't think anyone ever argued that frame pointers were a complete replacement for unwinding information. Maybe I missed that part of the discussion? _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
