Skip to content
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

Expose the -warn-stack-size= LLVM option somehow #79

Closed
whitequark opened this issue Apr 6, 2018 · 7 comments
Closed

Expose the -warn-stack-size= LLVM option somehow #79

whitequark opened this issue Apr 6, 2018 · 7 comments
Labels
feb-2019-cleanup These issues are proposed to be closed, as part of a cleanup of issues in February 2019

Comments

@whitequark
Copy link

I've just learned that LLVM can, in fact, do a limited stack size analysis: https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130603/177010.html.

It's not interprocedural but I think it's still quite useful e.g. if LLVM ends up allocating a large array on stack, which seems to be a source of stack overflows that might be on the second place after recursion IME.

@japaric
Copy link
Member

japaric commented Apr 7, 2018

In theory -C llvm-args=-warn-stack-size=$N should pass the flag to LLVM, but since these are warnings rustc won't report them to the console, I think.

I'm looking at the LLVM source code and it seems that there's some option to emit (as debug logs?) the number of stack bytes that each function uses. I have no idea how to make rustc print these statistics though.

Perhaps @nagisa or @eddyb can give us some clues here?

@whitequark
Copy link
Author

whitequark commented Apr 7, 2018

@japaric I think you need to call LLVMContextSetDiagnosticHandler. But probably a better idea is an LLVM patch that exposes this data directly in a proper format.

@jamesmunns
Copy link
Member

Hey @japaric, I know you've done some work exposing stack usage, is this issue still open/relevant?

@jamesmunns jamesmunns added the feb-2019-cleanup These issues are proposed to be closed, as part of a cleanup of issues in February 2019 label Feb 4, 2019
@japaric
Copy link
Member

japaric commented Feb 4, 2019

@jamesmunns the work I did was related to #106. The llvm feature described here is a different feature.

@jamesmunns
Copy link
Member

@japaric do you think this should stay open? If so, please remove the cleanup tag.

@japaric
Copy link
Member

japaric commented Mar 4, 2019

@jamesmunns not sure, but I can tell you that I don't intend to work on this one. We don't really have a policy for keeping "interesting project" issues around. Perhaps this could be moved into the "not yet awesome embedded Rust" list? Then we can close this issue.

@adamgreig
Copy link
Member

Closing this issue as part of today's triage. I'm sure there's still work to be done on improving stack size handling and overflow detection, but no one in the WG is currently planning to do it. There have been some interesting developments in handling stack overflows, such as flip-link, and newer Arm cores even have stack limit registers that are checked in hardware.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feb-2019-cleanup These issues are proposed to be closed, as part of a cleanup of issues in February 2019
Projects
None yet
Development

No branches or pull requests

4 participants