Tracking issue for -Z emit-stack-sizes

[japaric]

This is an experimental feature (i.e. there's no RFC for it) approved by the compiler team and added in #51946. It's available in nightly-2018-09-27 and newer nightly toolchains.

Documentation can be found in the unstable book.

[tgross35]

Just curious, is there anything specific needed to eventually move this to stable? It seems like the feature is relatively simple and stable, just based on the lack of changes for the past four years

[workingjubilee]

This does not offer useful support for all targets, it is unclear if it ever will, and LLVM generally seems to consider their CLI interface to be unstable to a degree we are loathe to do, so I do not think we should offer another "expose random LLVM knobs" flag without a clear plan for making it more useful and supporting it in the absence of LLVM support.

[workingjubilee]

Or e.g. "LLVM has major user orgs using this a lot, so it doesn't seem like LLVM will ever pull support for this, and LLVM has made it more useful for other targets in the past 4 years and will continue to". Or "the way this works can be eventually replaced with a few lines using object or something and not depend on a codegen backend" would also be a good answer for "why we should go ahead and stabilize this anyways"! Though the latter would raise the questions of "if we can use Rust code for this, why not just... do that, now?" and "If this is so easy to do, why does it require compiler support?"

So "how to move it along": investigate a bit further, try to anticipate future stability concerns and maybe develop a backup plan so we don't let people down in the future. Also hammer out any UX concerns, like e.g. figuring out if this should actually be a sub-option of a bigger CLI flag or something. Then bring it up to T-compiler, likely on Zulip, and discuss future moves with them.

It's hard to tell "very stable, happily used by many users in silence" apart from "fell through the cracks, works well but only in certain corner cases, is likely to bitrot and have its impl details removed the next release after its upstream LLVM implementer stops contributing". That happens when you have over 8000 open issues (of over 100 thousand total PRs and issues).

[keks]

Just want to say that I am using this feature to understand how large my call stack grows, in order to understand how badly we need to optimize in order to run on resource-constrained devices. It seems Rust is a pretty popular language for embedded development these days, so I believe I am probably not the only one.

What would make this a bit more helpful is if the it would write this to .stack-sizes.<mangled-fn-name> instead.

An orthogonal but equally helpful thing would be if rustc could also emit the original names of the hash suffixes, but I am not sure how easy that would be. For example, having a section .premangle._ZN3foo17habcdef0123456789 that contains foo<1337, alloc::vec::Vec<()>>.

[keks]

More evidence that this is used in the wild: Nitrokey/nitrokey-3-firmware#313, https://crates.io/crates/stack-sizes

I also noticed that the .rlib files also contain the .stack_sizes, but that doesn't seem to add up with the documentation, or am I missing something?

[workingjubilee]

the .rlibs are an unstable binary format as opposed to a stable user interface.