Skip to content

Support -C no-split-stack regardless of target triple #16980

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kmcallister opened this issue Sep 4, 2014 · 2 comments
Closed

Support -C no-split-stack regardless of target triple #16980

kmcallister opened this issue Sep 4, 2014 · 2 comments
Labels
A-codegen Area: Code generation

Comments

@kmcallister
Copy link
Contributor

See #14394, which was closed on the grounds that this should be determined solely by the target triple.

I want -C no-split-stack for my experiments making really tiny Linux binaries in Rust. In this case the target is the usual x86_64-unknown-linux-gnu, and rustc is built in the usual way for the platform.

It also seems useful for writing C libraries in Rust. We won't necessarily have __morestack available, and people who are already using C are more likely to want to compromise on this particular facet of memory safety.

This is a pretty big pain point — I'm currently running sed on the LLVM IR to fix it! There may be a more involved solution but the original PR was closed months ago and I'd like to have the simple fix ASAP. If people are okay with -C no-split-stack, I could revive the code from the PR. Or we could make it something like --unsafe-codegen-options no-split-stack.

@mahkoh
Copy link
Contributor

mahkoh commented Sep 4, 2014

I'd also like this. The flexible target specification can theoretically solve this but afaik you have to manually copy and modify one file for every platform for which you want to compile. This switch would make this much easier.

@brson
Copy link
Contributor

brson commented Sep 5, 2014

I'm ok with -C no-split-stack.

@kmcallister kmcallister added the A-codegen Area: Code generation label Sep 27, 2014
lnicola pushed a commit to lnicola/rust that referenced this issue Apr 20, 2024
fix: handle escaped chars in doc comments

fix rust-lang#16980.

For `ast::LiteralKind::String`, store the original string value.
lnicola pushed a commit to lnicola/rust that referenced this issue Apr 20, 2024
fix: handle escaped chars in doc comments

fix rust-lang#16980.

For `ast::LiteralKind::String`, store the original string value.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants