Rollup merge of rust-lang#145974 - pmur:murp/stabilize-zno-jump-tables, r=wesleywiser

Stabilize -Zno-jump-tables into -Cjump-tables=bool

I propose stabilizing the -Zno-jump-tables option into -Cjump-tables=<bool>.

# `-Zno-jump-tables` stabilization report
## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
No RFC was created for this option. This was a narrowly scoped option introduced in rust-lang#105812 to support code generation requirements of the x86-64 linux kernel, and eventually other targets as Rust For Linux grows.

The tracking is rust-lang#116592.

##  What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.

The behavior of this flag is well defined, and mimics the existing `-fno-jump-tables` option currently available with LLVM and GCC with some caveats:

* Unlike clang or gcc, this option may be ignored by the code generation backend. Rust can support multiple code-generation backends. For stabilization, only the LLVM backend honors this option.
* The usage of this option will not guarantee a library or binary is free of jump tables. To ensure a jump-table free binary, all crates in the build graph must be compiled with this option. This includes implicitly linked crates such as std or core.
* This option only enforces the crate being compiled is free of jump tables.
* No verification is done to ensure other crates are compiled with this option. Enforcing code generation options are applied across the crate graph is out of scope for this option.

What should the flag name be?
* As introduced, this option was named `-Zno-jump-tables`. However, other major toolchains allow both positive and negative variants of this option to toggle this feature. Renaming the option to `-Cjump-tables=<bool>` makes this option consistent, and if for some reason, expandable to other arguments in the future. Notably, many LLVM targets have a configurable and different thresholds for when to lower into a jump table.

## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those.
No. This option is used exclusively to gate a very specific class of optimization.

## Summarize the major parts of the implementation and provide links into the code (or to PRs)
* The original PR rust-lang#105812 by `@ojeda`
* The stabilized CLI option is parsed as a bool:
https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_session/src/options.rs#L2025-L2026
* This options adds an attribute to each llvm function via:
https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/compiler/rustc_codegen_llvm/src/attributes.rs#L210-L215
* Finally, the rustc book is updated with the new option:
https://github.com/pmur/rust/blob/68bfda9025ccb2778e2606e12e8021b9918f40d3/src/doc/rustc/src/codegen-options/index.md?plain=1#L212-L223

## Has a call-for-testing period been conducted? If so, what feedback was received?
No. The option has originally created is being used by Rust For Linux to build the x86-64 kernel without issue.

## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
There are no outstanding issues.

## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization

* `@ojeda` implemented this feature in rust-lang#105815 as  `-Zno-jump-tables`.
* `@tgross35` created and maintained the tracking issue rust-lang#116592, and provided feedback about the naming of the cli option.

## What FIXMEs are still in the code for that feature and why is it ok to leave them there?
There are none.

## What static checks are done that are needed to prevent undefined behavior?
This option cannot cause undefined behavior. It is a boolean option with well defined behavior in both cases.

## In what way does this feature interact with the reference/specification, and are those edits prepared?
This adds a new cli option to `rustc`. The documentation is updated, and the unstable documentation cleaned up in this PR.

## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?
No.

## What other unstable features may be exposed by this feature?
None.

## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.?
No support is required from other rust tooling.

## Open Items

- [x] Are there objections renaming `-Zno-jump-tables` to `-Cjump-tables=<bool>`? The consensus is no.
- [x] Is it desirable to keep `-Zno-jump-tables` for a period of time? The consensus is no.

---

Closes rust-lang#116592

Author: matthiaskrgr

compiler/rustc_codegen_llvm/src/attributes.rs

@@ -229,7 +229,7 @@ fn instrument_function_attr<'ll>(
 }
 
 fn nojumptables_attr<'ll>(cx: &SimpleCx<'ll>, sess: &Session) -> Option<&'ll Attribute> {
-    if !sess.opts.unstable_opts.no_jump_tables {
+    if sess.opts.cg.jump_tables {
         return None;
     }
 

compiler/rustc_interface/src/tests.rs

@@ -620,6 +620,7 @@ fn test_codegen_options_tracking_hash() {
     tracked!(force_frame_pointers, FramePointer::Always);
     tracked!(force_unwind_tables, Some(true));
     tracked!(instrument_coverage, InstrumentCoverage::Yes);
+    tracked!(jump_tables, false);
     tracked!(link_dead_code, Some(true));
     tracked!(linker_plugin_lto, LinkerPluginLto::LinkerPluginAuto);
     tracked!(llvm_args, vec![String::from("1"), String::from("2")]);
@@ -831,7 +832,6 @@ fn test_unstable_options_tracking_hash() {
     tracked!(mutable_noalias, false);
     tracked!(next_solver, NextSolverConfig { coherence: true, globally: true });
     tracked!(no_generate_arange_section, true);
-    tracked!(no_jump_tables, true);
     tracked!(no_link, true);
     tracked!(no_profiler_runtime, true);
     tracked!(no_trait_vptr, true);

compiler/rustc_session/src/options.rs

@@ -2093,6 +2093,8 @@ options! {
         "instrument the generated code to support LLVM source-based code coverage reports \
         (note, the compiler build config must include `profiler = true`); \
         implies `-C symbol-mangling-version=v0`"),
+    jump_tables: bool = (true, parse_bool, [TRACKED],
+        "allow jump table and lookup table generation from switch case lowering (default: yes)"),
     link_arg: (/* redirected to link_args */) = ((), parse_string_push, [UNTRACKED],
         "a single extra argument to append to the linker invocation (can be used several times)"),
     link_args: Vec<String> = (Vec::new(), parse_list, [UNTRACKED],
@@ -2475,8 +2477,6 @@ options! {
         "omit DWARF address ranges that give faster lookups"),
     no_implied_bounds_compat: bool = (false, parse_bool, [TRACKED],
         "disable the compatibility version of the `implied_bounds_ty` query"),
-    no_jump_tables: bool = (false, parse_no_value, [TRACKED],
-        "disable the jump tables and lookup tables that can be generated from a switch case lowering"),
     no_leak_check: bool = (false, parse_no_value, [UNTRACKED],
         "disable the 'leak check' for subtyping; unsound, but useful for tests"),
     no_link: bool = (false, parse_no_value, [TRACKED],

src/doc/rustc/src/codegen-options/index.md

@@ -209,6 +209,27 @@ Note that while the `-C instrument-coverage` option is stable, the profile data
 format produced by the resulting instrumentation may change, and may not work
 with coverage tools other than those built and shipped with the compiler.
 
+## jump-tables
+
+This option is used to allow or prevent the LLVM codegen backend from creating
+jump tables when lowering switches from Rust code.
+
+* `y`, `yes`, `on`, `true` or no value: allow jump tables (the default).
+* `n`, `no`, `off` or `false`: disable jump tables.
+
+To prevent jump tables being created from Rust code, a target must ensure
+all crates are compiled with jump tables disabled.
+
+Note, in many cases the Rust toolchain is distributed with precompiled
+crates, such as the core and std crates, which could possibly include
+jump tables. Furthermore, this option does not guarantee a target will
+be free of jump tables. They could arise from external dependencies,
+inline asm, or other complicated interactions when using crates which
+are compiled with jump table support.
+
+Disabling jump tables can be used to help provide protection against
+jump-oriented-programming (JOP) attacks.
+
 ## link-arg
 
 This flag lets you append a single extra argument to the linker invocation.

src/doc/unstable-book/src/compiler-flags/no-jump-tables.md

@@ -1,10 +1,10 @@
-// Test that jump tables are (not) emitted when the `-Zno-jump-tables`
+// Test that jump tables are (not) emitted when the `-Cjump-tables=no`
 // flag is (not) set.
 
 //@ revisions: unset set
 //@ assembly-output: emit-asm
 //@ compile-flags: -Copt-level=3
-//@ [set] compile-flags: -Zno-jump-tables
+//@ [set] compile-flags: -Cjump-tables=no
 //@ only-x86_64
 //@ ignore-sgx
 

tests/assembly-llvm/x86_64-no-jump-tables.rs

@@ -1,11 +1,12 @@
 // Test that the `no-jump-tables` function attribute are (not) emitted when
-// the `-Zno-jump-tables` flag is (not) set.
+// the `-Cjump-tables=no` flag is (not) set.
 
 //@ add-core-stubs
-//@ revisions: unset set
+//@ revisions: unset set_no set_yes
 //@ needs-llvm-components: x86
 //@ compile-flags: --target x86_64-unknown-linux-gnu
-//@ [set] compile-flags: -Zno-jump-tables
+//@ [set_no] compile-flags: -Cjump-tables=no
+//@ [set_yes] compile-flags: -Cjump-tables=yes
 
 #![crate_type = "lib"]
 #![feature(no_core, lang_items)]
@@ -19,5 +20,6 @@ pub fn foo() {
     // CHECK: @foo() unnamed_addr #0
 
     // unset-NOT: attributes #0 = { {{.*}}"no-jump-tables"="true"{{.*}} }
-    // set: attributes #0 = { {{.*}}"no-jump-tables"="true"{{.*}} }
+    // set_yes-NOT: attributes #0 = { {{.*}}"no-jump-tables"="true"{{.*}} }
+    // set_no: attributes #0 = { {{.*}}"no-jump-tables"="true"{{.*}} }
 }