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

rustc_codegen_llvm should mark more of its internal methods as unsafe #131562

Open
clarfonthey opened this issue Oct 11, 2024 · 6 comments
Open
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@clarfonthey
Copy link
Contributor

Just following up from this comment I made here: #85532 (comment)

While LLVM compiled with asserts ensures that no undefined behaviour occurs when calling methods, it does not when compiled without asserts, and this should really be reflected in the signatures for all the various internal methods that just call out to LLVM FFI.

Right now, it's very easy to trigger UB when you're writing an intrinsic, and while it's common for C functions to have all sorts of undocumented preconditions, we should not extend this habit into Rust.

For example, const_array will trivially trigger UB if any of the Values passed into it are not actually constant:

And extract_value will trigger UB if the index is out of bounds for the given Value:

Whereas something like type_i1 is fine and will always be safe to call:

Sure, this will "introduce" unsafe code to, for example, the intrinsics lowering, but the code was already unsafe, and this is just documenting that.

@rustbot label T-compiler

@rustbot rustbot added needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 11, 2024
@RalfJung
Copy link
Member

Yeah I also ran into this, e.g. calling AddFunctionAttributes or AddCallSiteAttributes on the wrong thing / with an out-of-bounds index can lead to segfaults. These should all be unsafe functions with documented preconditions (or, ideally, get a safe wrapper).

@clarfonthey
Copy link
Contributor Author

In my case, I was getting far worse than segfaults: illegal instructions. And worse, since it was UB, the resulting errors did not occur with a useful stack trace pointing out where the error was, which is why I mentioned assertions being so helpful. rustc can handle segfaults sometimes in FFI, but SIGILL will always abort the process, meaning the only way to properly debug is to open up the core dump in a debugger.

@RalfJung
Copy link
Member

TBH I don't remember whether it was SEGFAULT or SIGILL... it was an abrupt abort and I debugged it by staring hard at my code until I realized where the wrong call must be.^^

@jieyouxu jieyouxu added the C-bug Category: This is a bug. label Oct 12, 2024
@lolbinarycat lolbinarycat added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness labels Nov 1, 2024
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Nov 1, 2024
@apiraino
Copy link
Contributor

apiraino commented Nov 4, 2024

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-low

@rustbot rustbot added P-low Low priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Nov 4, 2024
@jieyouxu jieyouxu removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 4, 2024
@jieyouxu
Copy link
Member

jieyouxu commented Nov 4, 2024

Triage: this is probably more of a tracking issue for cg_llvm so someone interested can try to minimize + annotate things as unsafe and document their expected usage contracts to make cg_llvm less footgunny.

@Noratrieb Noratrieb removed the I-unsound Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness label Nov 4, 2024
@Noratrieb
Copy link
Member

Not a soundness hole in the language.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants