Repository navigation
Don't force-enable frame pointers when generating debug info #48785
Description
In #47152, we decided to add a flag to force enable frame pointers (that is, to prevent the compiler from optimizing them away). This flag was to be insta-stable because it is needed, e.g. to help profilers like perf that need to reconstruct the stack. @dotdash then came back with a few proposed changes. Unfortunately, they were never able to finalize the rebase, and the PR was closed by triage for inactivity. This is where you come in, dear reader! Perhaps you can help us!
There was some dispute about what the final interface ought to be though. @dotdash proposed -Comit-frame-pointer=[yes|no], but @Mark-Simulacrum proposed -Cframe-pointers=[auto, yes, no], which seems logical enough.
However we say it, the default behavior (when user says nothing) probably wants to be:
- If debuginfo is enabled, keep them.
- If not optimizing, keep them.
- Follow behavior of either gcc or clang:
- GCC has the -fomit-frame-pointer option, default off on "32-bit GNU/Linux x86 and 32-bit Darwin x86 targets", but otherwise on it seems if optimizing.
- clang always retains frame pointers on darwin by default
- cl.exe will always keep frame pointers by default for unoptimized builds
Activity
nikomatsakis commentedon Mar 6, 2018
cc @rust-lang/compiler -- we should settle on a plan here, no?
nagisa commentedon Mar 6, 2018
-Cframe-pointers=valmatches our current direction of CLI design. We should change to that ASAP if we want to keep the compatibility.The defaults can always be changed later, though. The default should be specified in the target files.
I’ll fiddle with this.
Rollup merge of rust-lang#48786 - nagisa:fp, r=nikomatsakis
Auto merge of #48786 - nagisa:fp, r=nikomatsakis
jonhoo commentedon Sep 21, 2018
Should this be closed given that #48786 has landed?
sfackler commentedon Sep 21, 2018
I think so!