Change:
cargo.rustflag("-Cforce-unwind-tables=yes"); } <ins> // Enable frame pointers by default for the library. Note that they are still controlled by a // separate setting for the compiler. cargo.rustflag("-Cforce-frame-pointers=yes"); </ins> let html_root = format!("-Zcrate-attr=doc(html_root_url="{}/")", builder.doc_rust_lang_org_channel(),); cargo.rustflag(&html_root);

Discussion:
The compiler flag isn't always honored, clobbering the register and resulting in the unrecoverable stackframe for . It seems that if I compile under , it works as shown below: I picked for the above example. But it seems that there's many: I suspect this is caused by pre-built fn machine code is statically linked into the binary, skipping compilation and not considering .
That's probably prebuilt code shipped with the standard library, have you tried using (requires nightly)?
so, this is a known issue? hopefully, a warn or something can be printed without being too noisy?
Since this also applies to other codegen options (e.g. optimization levels) almost everyone setting RUSTFLAGS would get that warning. Maybe it could be documented in the cargo book.
What would be the appropriate place to raise this issue regarding building the precompiled rustc binaries that rustup distributes with frame-pointers enabled?
I am assuming the final comment by is essentially the "real issue" here and leaving because it's not clear to me what the answer is, however it is of some concern to the compiler and library team, since it has to do with how std is built and shipped. Unless is accepted as the canonical option, of course, but it doesn't seem like it would be clear to users why they would need to rebuild to support frame pointers, rather than that being done implicitly.
I guess there are 2 or maybe 3 different issues here probably: Having frame pointers be the default in more platforms (and rustup will probably ship the default build then) Honoring and rebuilding the std if the existing install doesn't match Stabilizing -Zbuild-std maybe? All kinda related, but also can be tackled independently I think
I think there are 3 ways to address this question, with varying tradeoffs: frame pointers by default in distributed stdlib. This may have overhead, but we have some benchmarking so we should be able to provide some answer. This is by far the easiest option: the standard library as MIR-only rlibs, which is a theoretical idea that nobody has implemented. The now-dead tracking issue was I am interested in this for other reasons, so I might make progress here, but pulling this off would probably be very messy. For example, just trying to blindly enable produces multiple definition errors when bootstrapping, and undefined symbol errors when combined with .

work on a stable compiler. This effort has its own repo for tracking issues: as well as a tag here: There seems to be some activity on that repo this year which is nice, but I'm not holding my breath. There's a lot of work to do still.
Enabling frame-pointers I think it's the easiest option and developers will thank you for it. There is gonna be backlash from all the people with an opinion on the internet but I think the issue is pretty clear for any person that ever profiled an application. CPython is also making frame-pointers mandatory for 3.12 last I heard.
Even with still allowing frame pointer elision for leaf functions, it induced a pretty hard compiler performance hit (test results in if you're wondering). I'm not sure if I could sell the compiler performance WG on it, much less the entire Rust community, despite frame pointers usually helping profiling.
Hmm, this is definitely a place where using instructions is sub-optimal, though, because it'll clearly be more instructions -- it has to be, to maintain them -- but that means the "they're a fine proxy for speed because it'll be about the same run-to-run" argument for looking at them most of the time doesn't apply. If you instead look at its wall-time results and include everything (not just the regressions/improvements), then it's: check +0.08% debug +0.34% opt +0.16% doc +0.61% That's not nothing, but I think it's a better summary than the "+1.5%" that the instruction-count-changes summary shows. I still don't know that it's small enough to say "yeah, of course just take it", but it doesn't seem entirely unreasonable either. Maybe we could find the functions where most of the impact is coming from and them so they'll be compiled in the caller's context -- without frame pointers for the people who don't want them -- and then it'd be fine to have them in the rest of the places? Like having frame pointers in all the time seems fine, since anything where that's the perf bottleneck has bigger problems.
(Just found my way here through random thread-hopping and want to add whatever persuasive/rhetorical weight I can: having frame pointers everywhere by default is so, so worth the sprinkling of instructions it costs. Please do try to turn them on!)

Hey, I also recently got hit by this issue while using on MacOS because of I also want to point out that increased ability to profile code will unlock much greater optimizations than the raw perf loss, specially at ~1% or less. It will also get closer to perf tools "just working".
The perf numbers being discussed here are about the performance of the compiler, not of user code. When hacking on the compiler we don't use a precompiled standard library, so limitations like this issue which are caused by the build configuration used for the precompiled standard library do not affect the compiler dev workflow. I agree with the plain "the small icount regression is worth the improved behavior" argument, but not "we'll claw back that 1% via optimizations people find because profiling is easier".
Worth pointing out that Fedora and Ubuntu are switching to having frame pointers everywhere as well. There's a good write-up about the what and why here: I wonder if we could update the Rust default to simply always enable them?
As-of we now have frame pointers enabled in the stdlib! This does not "enable frame pointers by default", but it resolves the primary concern here and the one the issue title is actually about. For those wanting to recommend we enable frame pointers by default, it may be best to and perhaps first get answers to some questions like "wait, doesn't the aarch64 call ABI use frame-pointers anyways? so the perf regressions, such as they are, don't necessarily materialize on all platforms? has anyone checked the assembly to verify this?"