allow overriding frame pointer defaults

[ratmice]

When using a Cargo.toml such containing:

debug = true

cc-rs will automatically add -fno-omit-frame-pointer which affects code generation,
in my opinion there should be a way to enable debug info, without affecting the resulting code generation.

This patch attempts to do so, by only adding -fno-omit-frame-pointer if the target profile is debug
rather than if debuginfo is enabled. I imagine it's somewhat debatable the right way to make this possible.

[alexcrichton]

I've personally used this before because frame pointers assist in profiling by making stack traces easier for some tools (like perf). It's true that it's unfortunate that it affects runtime performance as well, but I think that we'd probably want an explicit option for this rather than inference based on existing settings.

[ratmice]

I was actually comparing a rust program in perf, to the equivalent system executable. On some systems frame pointers are required, but others can be done with just dwarf and the .eh_frame section.

After sending the request I noticed rustc now has: -C force-frame-pointers=yes|no
Would it be better to rework this based upon the rustc flags/RUSTFLAGS environment variable,
leaving the current behavior unless force-frame-pointers=no? Or is there some value in keeping the cc flags and rust flags distinct?

[alexcrichton]

Yeah if we could infer from RUSTFLAGS that would be great, although I'm not sure how to best do that myself

[ratmice]

I did have a bit of a look at this, the only thing that would inhibit this from being straight forward argument parsing is the unstable feature Implement argsfile, depending on the compiler version we may have to chase the options around the filesystem.

In many ways, it seems like an ugly hack of using serde in the compiler to serialize some struct containing all of the options, and setting that in an environment variable would be really nice.
But i'm not certain if that is a viable option due to adding depending on serde in rustc.

[alexcrichton]

Failing auto-inference of an option, having a separate config for this crate seems reasonable. Not a great UI, but gets the job done.

[ratmice]

argh, it seems like renaming the issue for some reason canceled all the jobs?,
seems to be something with rustup.

This probably needs some work in specifying the option for other compilers besides gcc/clang.

[alexcrichton]

Looks great to me, no need to worry about the CI errors, thanks!