New codegen option "no-split-stack"

[vhbit]

Allows to compile for archs which do not have (or have limited) segmented stack support like embedded/iOS

CLI usage:
rustc -C no-split-stack test.rs

[emberian]

This feature has previously been rejected because it makes calling a function memory-unsafe. See #8345 and #8955.

I think this should be rejected on the same grounds as #8955. I wrote http://blog.octayn.net/blog/2013/10/21/on-stack-safety/ and http://blog.octayn.net/blog/2013/10/28/more-on-stack-safety/, I should probably write an update.

[emberian]

"Teach the task API to allow spawning a task with a fixed stack size" is done. I started implementing "Add the ability to query stack size from LLVM. This lets us implement stack guard zones precisely" but ran into limitations of LLVM's pass infrastructure, and didn't feel like putting in the effort to continuing. I'm still fond of a separate post-trans static analysis of fixed stack size. One possibility is also using attributes to tag function pointers with a "maximum stack size", so that indirection can still be used, albeit with this limitation.

[alexcrichton]

Over time I've softened on adding a feature such as this. Segmented stacks unquestionably hurts our portability because LLVM does not have segmented stacks implemented for all platforms. In the light of that, I believe that there is likely a compromise to be made here.

The best of all worlds would be that we don't require segmented stack support in LLVM (allowing us to be more portable), but it's unclear how easily we can get there. Until that date comes, it seems inevitable that we need something such as this.

As for dealing with this specifically, I have a few preferences with how I may want it to be changed:

1. No-split-stack crates should not be able to link against split-stack crates (and vice versa).
2. This may want to be a -Z option instead of -C because it is an implementation detail that is subject to change in the future (we may not have -C no-split-stacks for all time).

[emberian]

In the past I had proposed that but there was concern that that would induce undesirable segmentation between libraries. I'm still in favor of it.

[vhbit]

Aha, it's completely new perspective for me.
I've addressed a bit different issue - with no LLVM support it is simply impossible to compile for a platform like iOS.

I agree that it shouldn't reduce safety on platforms which have first-class SS support. I think that segmentation between libraries could be a nightmare so perhaps the only solution is to leave it as a codegen option but do not expose it through CLI and enable/disable internally in compiler based on target triple, for example like it works now for iOS: https://github.com/vhbit/rust/blob/744b10196b6664ecc269389f069f9742632baee4/src/librustc/driver/session.rs#L219

[emberian]

Doing it based on target triple is a great idea! I'm fully behind that.
It'd mesh really well with the UnknownOs that has been proposed.

On Sun, May 25, 2014 at 11:40 PM, Valerii Hiora notifications@github.heygears.comwrote:

Aha, it's completely new perspective for me.
I've addressed a bit different issue - with no LLVM support it is simply
impossible to compile for a platform like iOS.

I agree that it shouldn't reduce safety on platforms which have
first-class SS support. I think that segmentation between libraries could
be a nightmare so perhaps the only solution is to leave it as a codegen
option but do not expose it through CLI and enable/disable internally in
compiler based on target triple, for example like it works now for iOS:
https://github.com/vhbit/rust/blob/744b10196b6664ecc269389f069f9742632baee4/src/librustc/driver/session.rs#L219

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/14394#issuecomment-44161266
.

http://octayn.net/

[alexcrichton]

cc #11871

[Tobba]

This is pretty much necessary to write a kernel right now, and everyone does it through various mainly retarded ways

Theres no reason not to land this, a proper way to have checked stacks can be added before 1.0

[taralx]

+1 to this. It's one of my two blockers to hack-free Pebble smartwatch apps. (The other is an LLVM bug.)

[taralx]

FYI this option may make more sense in the -Z lto world (which embedded systems will almost certainly use). At that point you just have one module that you can strip split-stack from.

[nikomatsakis]

I like the idea of doing it based on target triple.

[alexcrichton]

Talking with others, it seems that the consensus for now is that this shouldn't be done as a codegen option, but rather enabled/disabled for particular triples. None of the currently supported triples should have segmented stacks disabled, so I'm going to close this for now.

We'd love to have more support for more triples, though! New triples supported in the compiler can opt-out of using split stacks on a case-by-case basis.

[vhbit]

@alexcrichton Codegen option and enabling/disabling triples aren't opposed to each other since codegen option isn't exposed to the user and will be triggered only internally based on triple. I still think that it is the best way to pass it from driver to back.

None of the currently supported triples should have segmented stacks disabled

It's actually was a preparation step for iOS PR[1] which (based on prev experience) can take more time to land and I thought it might be useful for others too to use independently. Let me know how it will be better to proceed in this case - should we discuss a better shape for it and land independently or should it be a part of iOS PR.

[1]: it requires upstreaming jemalloc changes, wip

[alexcrichton]

It's true that having an option would in theory be orthogonal to disabling/enabling per target triple, but we feel a per-target-triple setting is the best way to go at this time.

For the iOS PR, you'd just disable segmented stacks for the iOS triple, but not for other triples.