Allow profiles to set -Cforce-frame-pointers

[davidlattimore]

Problem

When profiling Rust code on Linux using perf, I can either use perf record with --call-graph=dwarf or I can enable frame pointers during the build by passing -Cforce-frame-pointers to rustc. With frame pointers, a perf run is substantially faster to process. My understanding is that this is because stack traces can be captured in the kernel with eBPF, which can follow the frame pointers, whereas with debug info it's all done by calling addr2line after the fact.

For a profiling run I just did, it took more than 8 minutes to process the perf data when using debug info and less than a second when using frame pointers.

I'd like to be able to turn on frame pointers for a particular profile in my Cargo.toml. Currently, I instead turn it on globally in my ~/.cargo/config.toml.

Proposed Solution

Add force-frame-pointers as an option in cargo profiles. e.g.

[profile.profiling]
inherits = "release"
force-frame-pointers = true

Notes

If it's agreed that this is a reasonable feature to add, I'm happy to implement it.

[hanna-kruppe]

Currently, I instead turn it on globally in my ~/.cargo/config.toml.

Note that these config settings don’t have to be global, you can add a .cargo/config.toml file to your workspace root for example. Not quite a replacement for a profile setting for several reasons but FYI.

[ehuss]

The cargo team briefly discussed this, and agreed that it seemed like a reasonable thing to add.
We noted some minor details, such as what exact values it accepts. It would probably need some option that means to "use the default", since we've generally run into problems when we don't have that.

It was also asked whether or not this would need to be unstable or not, though a small change it probable isn't needed.

[brvtalcake]

It would probably need some option that means to "use the default", since we've generally run into problems when we don't have that.

Alright, so what should be the valid options ? Should it accept just booleans, or something else ?

I feel like the only value worth handling is true, since forwarding a false to the compiler would anyway be the same thing as keeping the defaults (at least it seems like, as per the documentation, but it's a bit unclear so I'm not sure).

And even if it's not the case, users wanting more control could as well use the unstable profile-rustflags, so we keep the force-frame-pointers option only to allow for cases where one may really want these frame pointers.

[epage]

I feel like the only value worth handling is true, since forwarding a false to the compiler would anyway be the same thing as keeping the defaults (at least it seems like, as per the documentation, but it's a bit unclear so I'm not sure).

The fact that the compiler has a false state has me question this but I agree the docs are unclear.

Overall, I'd find it confusing that force-frame-pointers = false does not map to -Cforce-frame-pointers=false/off

If false is meaningful, then we'd need to also know when to not pass -Cforce-frame-pointers at all.

[brvtalcake]

The fact that the compiler has a false state has me question this but I agree the docs are unclear.

Yes, exactly

Overall, I'd find it confusing that force-frame-pointers = false does not map to -Cforce-frame-pointers=false/off

I can understand that, and that's true. But I thought it would be a bit of a duplicate with the profile-rustflags feature. Tell me and I will change the code to properly forward any provided value to rustc

If false is meaningful, then we'd need to also know when to not pass -Cforce-frame-pointers at all.

You're right. I will quickly look at rustc's handling of the option. Otherwise something akin to the lto option could be OK ?

[epage]

. Otherwise something akin to the lto option could be OK ?

lto looks to be a pretty complex profile setting, so saying to do something like it carries a lot of weight that I assume you don't intend.