Add rtsan #1

luca3s · 2025-06-28T21:25:16Z

No description provided.

cjappl

Left some comments in terms of wording.

Overall, I'm feeling a little uneasy about officially exposing these internal calls to some official release. I'm going to ping @davidtrevelyan so we can discuss more about it.

Another thought, on a different note: Is there any way that we can have one single construct that does the entry and exit at all entry points? In C++ this would be called RAII, similar to ScopedMutex, preventing a call from .lock() from ever being unmatched from a .unlock().

I worry that something like ? would bubble up some error and leave the sanitizer in a bad state where it's been entered, but not exited. Interested to hear your thoughts on this one, or maybe Stephan has already figured it out for the standalone?

compiler/rustc_session/src/options.rs

cjappl · 2025-06-28T21:29:16Z

src/bootstrap/src/core/build_steps/llvm.rs

-        "x86_64-apple-darwin" => darwin_libs("osx", &["asan", "lsan", "tsan"]),
+        "x86_64-apple-darwin" => darwin_libs("osx", &["asan", "lsan", "tsan", "rtsan"]),
        "x86_64-unknown-fuchsia" => common_libs("fuchsia", "x86_64", &["asan"]),
        "x86_64-apple-ios" => darwin_libs("iossim", &["asan", "tsan"]),


I believe this should be supported as well, we create an ios library when we build

This is x86_64 ios, I don't even know how that is used. Regular arm ios i already have added. But just making sure, if it is supported i will of course add it.

cjappl · 2025-06-28T21:29:41Z

src/bootstrap/src/core/build_steps/llvm.rs

+        "x86_64-unknown-linux-gnu" => common_libs(
+            "linux",
+            "x86_64",
+            &["asan", "dfsan", "lsan", "msan", "safestack", "tsan", "rtsan"],


I think these were in in alpha order

I don't think so. "hwsan" in aarch linux gnu was at the end before. So not really ordered.

cjappl · 2025-06-28T21:30:25Z

src/doc/unstable-book/src/compiler-flags/sanitizer.md

  * [LeakSanitizer](#leaksanitizer) a run-time memory leak detector.
  * [MemorySanitizer](#memorysanitizer) a detector of uninitialized reads.
  * [ThreadSanitizer](#threadsanitizer) a fast data race detector.
+  * [RealtimeSanitizer](#realtimesanitizer) a detector of blocking functions


I would maybe go with "non-deterministic execution time calls in real-time contexts".

(as a side note in our docs and presentations we were trying to go with real-time over realtime. This is a matter of preference but it would be good to stick with what we decided back then)

src/doc/unstable-book/src/compiler-flags/sanitizer.md

cjappl · 2025-06-28T21:37:41Z

src/doc/unstable-book/src/compiler-flags/sanitizer.md

+  pub fn __rtsan_realtime_enter();
+  /// Exits a realtime context. After calling this the program could still be in a realtime context,
+  /// as they can be nested.
+  pub fn __rtsan_realtime_exit();


Possible addition around these first two "Each call to enter must be matched with exactly one call to exit. Anything else leads to undefined behavior in the sanitizer."

I believe we have a similar note in our official docs if you want to check out that wording.

cjappl · 2025-06-28T21:39:17Z

src/doc/unstable-book/src/compiler-flags/sanitizer.md

+  pub fn __rtsan_enable();
+  /// Should be called before any other sanitizer calls are made.
+  pub fn __rtsan_ensure_initialized();
+  /// Notify the sanitizer that a blocking function was called. This will trigger a violation report.


"To mark your function as not safe for real-time contexts, place this call as the first line in the function. If rtsan hits this call while in a real-time context it will abort in the same way that calling an illegal system call does"

I tried to avoid mentioning "safe" or "unsafe". I think my version is still fine.

EDIT: whoops the new version wasn't showing up on my phone, will review on my computer later!!

cjappl · 2025-06-28T21:40:27Z

src/doc/unstable-book/src/compiler-flags/sanitizer.md

+  /// Disables the sanitizer.
+  pub fn __rtsan_disable();
+  /// Enables the sanitizer again.
+  pub fn __rtsan_enable();


"These two calls allow you to disable the sanitizer for a given scope. Useful for situations where you know some system call has deterministic execution time under the hood"

src/doc/unstable-book/src/compiler-flags/sanitizer.md

src/tools/compiletest/src/header/needs.rs

luca3s · 2025-06-28T21:54:42Z

Overall, I'm feeling a little uneasy about officially exposing these internal calls to some official release. I'm going to ping @davidtrevelyan so we can discuss more about it.

This will only ever go into rust nightly. I thought about adding a explicit comment that this API has the same stability promise as rust nightly (so basically none). Do you think that would be helpful?
Also once the attributes exist in the rust compiler i will probably delete this section from the docs.

Another thought, on a different note: Is there any way that we can have one single construct that does the entry and exit at all entry points? In C++ this would be called RAII, similar to ScopedMutex, preventing a call from .lock() from ever being unmatched from a .unlock().

Yeah in the standalone we use RAII. the issue is that i can't put anything in the rust stdlib. So i guess i could add a comment about that in the docs here. We could do a library (or add it to this https://github.com/rcvalle/rust-crate-sanitizers) that would expose this structure, but otherwise everyone who uses this would have to copy these ffi definitions and maybe the RAII struct definition. This of course isn't really ergonomic, and it won't be necessary once the attribute exists in rust.

cjappl

docs look good, I think we should get to the bottom of the API exposure before putting it against the upstream. I have pinged David

cjappl · 2025-06-29T15:54:29Z

src/doc/unstable-book/src/compiler-flags/sanitizer.md

 # RealtimeSanitizer
-RealtimeSanitizer detects blocking calls in realtime contexts. If enabled,
-it won't sanitize the whole program, it needs to be enabled explicitly.
+RealtimeSanitizer detects non-deterministic execution time calls in realtime contexts.


"real-time contexts"

cjappl · 2025-06-29T15:55:14Z

src/doc/unstable-book/src/compiler-flags/sanitizer.md

  pub fn __rtsan_realtime_exit();
-  /// Disables the sanitizer.
+  /// Disables the sanitizer. Must be matched to a later call to `__rtsan_enable()`.
+  /// Useful for situations where you know the systemcall you do has a deterministic execution time.


system call

cjappl · 2025-06-29T15:55:21Z

src/doc/unstable-book/src/compiler-flags/sanitizer.md

  pub fn __rtsan_disable();
-  /// Enables the sanitizer again.
+  /// Enables the sanitizer again. Must be matched to a preceding call to `__rtsan_disable()`.
+  /// Useful when you know that a systemcall you do has a deterministic execution time in that situation.


system call

luca3s · 2025-08-14T14:11:28Z

Isn't relevant anymore as we now use the new attribute.

…=jieyouxu Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#1 of Batch #2] Part of rust-lang#133895 Methodology: 1. Refer to the previously written `tests/ui/SUMMARY.md` 2. Find an appropriate category for the test, using the original issue thread and the test contents. 3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers) 4. Rename the tests to make their purpose clearer Inspired by the methodology that `@Kivooeo` was using. r? `@jieyouxu`

luca3s and others added 2 commits June 28, 2025 23:21

add realtime sanitizer

b2dee18

add docs

5e822fb

cjappl reviewed Jun 28, 2025

View reviewed changes

luca3s added 2 commits June 29, 2025 16:50

wording comments 1

dea84bc

compiler comments 1

a8baf35

cjappl reviewed Jun 29, 2025

View reviewed changes

luca3s closed this Aug 14, 2025

luca3s deleted the add-rtsan branch August 14, 2025 19:09

Add rtsan #1

Add rtsan #1

Uh oh!

Conversation

luca3s commented Jun 28, 2025

Uh oh!

cjappl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

luca3s commented Jun 28, 2025

Uh oh!

cjappl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

luca3s commented Aug 14, 2025

Uh oh!

Uh oh!