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

[pmur]

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

-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 #105812 to support code generation requirements of the x86-64 linux kernel, and eventually other targets as Rust For Linux grows.

The tracking is #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 Add -Zno-jump-tables #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 Extend -Zdump-mir output with two-phase borrow info #105815 as -Zno-jump-tables.
• @tgross35 created and maintained the tracking issue Tracking Issue for no-jump-tables #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

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

---

Closes #116592

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jieyouxu]

Question [GUARANTEE 1/3]: is this intended to be a hint, or a guarantee?

[pmur]

This is guarantee for the crate being compiled. No attempts are made to verify the entire link unit is compiled with this flag.

I think that is OK. It may be desirable for some crates to control this option. A jump table isn't always a more performant optimization (such was my experience when experimenting with them on Go/PPC64).

[tgross35]

Maybe it's worth mentioning in the docs that:

• This can be enabled for a single crate if you are interested in controlling this for performance reasons
• If you are going after IBT concerns, it probably needs to be enabled for all crates in the graph
• Pre-built std may not meet your requirements

(Great questions btw Jieyou)

[jieyouxu]

Yeah, this is why I asked, because depending on what you are aiming for, perf-only versus security concerns might want different levels of guarantees (or don't need guarantees).

[pmur]

For clarification, is this a concern with the implementation or documentation? If the latter, I wonder what the most appropriate wording is. If the flag is not consistently used for all crates, this option is most likely a hint. I am unsure how this attribute survives through inlining and LTO of crates which don't enable this option.

[jieyouxu]

Both, but I find the present wording to be sufficiently clear for this distinction.

[jieyouxu]

Question:

This option enables the -fno-jump-tables flag for LLVM, which makes the codegen backend avoid generating jump tables when lowering switches.

This option adds the LLVM no-jump-tables=true attribute to every function.

The option can be used to help provide protection against jump-oriented-programming (JOP) attacks, such as with the linux kernel's IBT.

How does this interact with pre-compiled std? I.e. can you mix downstream user crates compiled with -Cjump-tables=no versus a pre-compiled std compiled and distributed with -Cjump-tables=yes?

[pmur]

It should link without issue. Disabling this codegen optimization should have no effect on ABI.

[jieyouxu]

Discussion: Hm, what happens if a different cg backend is selected?

cc @GuillaumeGomez @antoyo

[antoyo]

It is not implemented yet in cg_gcc, but I guess it could be by sending -fno-jump-tables with context.add_driver_option("-fno-jump-tables") or context.add_command_line_option("-fno-jump-tables").

[pmur]

Should this be implemented for the other backends before stabilizing?

[tgross35]

I don't think we need to block on it, though it may be worth a note. For GCC it should be a simple check here

rust/compiler/rustc_codegen_gcc/src/base.rs

Line 96 in fe55364

fn module_codegen(

, I think it should be fine to add a commit doing that to this PR if you're up for it.

(assuming Antoni is okay with doing it here rather than the submodule repo to avoid dancing also dancing around the name change).

Cc @bjorn3 for cranelift

[bjorn3]

Cranelift doesn't have support emission of jump tables for the br_table instruction. Avoiding emitting br_table itself may be feasible, but would require a cranelift-frontend change. FWIW cg_clif silently ignores many of these flags already.

[antoyo]

(assuming Antoni is okay with doing it here rather than the submodule repo to avoid dancing also dancing around the name change).

I'm OK with this.

[pmur]

Adding support to the gcc backend seems straightforward. What is the difference between using add_driver_option vs add_command_line_option? The former did inhibit jump tables when I tested it.

[tgross35]

It looks like maybe precedence? https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#c.gcc_jit_context_add_command_line_option

[antoyo]

Some options won't work if not using the correct function. If it works, all is good.

[jieyouxu]

Should this be implemented for the other backends before stabilizing?

Given that only the LLVM codegen backend is "stably" supported, it is not a stabilization blocker.

[jieyouxu]

Question: I'm assuming that if you inspect the assembly of an actual hello world binary that uses std in some way, then you might see jump stables still? 🤔

[pmur]

Yes, if they exist and are included when linking. That is expected, though unintuitive to someone unfamiliar with the rust build system.

[ojeda]

Thanks for this!

and eventually other targets as Rust For Linux grows

Yeah, it may get used for other things. Apart from what I mentioned in the original PR, I see LoongArch also uses it since a year ago (so I assume it should be passed for Rust too there, Cc @chenhuacai in case there is a reason not to).

Are there objections renaming -Zno-jump-tables to -Zjump-tables=<bool>?

I assume you mean -C for the latter, i.e. we are going directly from -Zno-jump-tables to -Cjump-tables rather than one more step -- that is what the PR seems to do, right? Otherwise, we will need to support 3 names on the kernel side, which isn't great.

As for the name change, it seems fine -- the usual argument for using the current name is to keep it close to GCC's and Clang's flags, which always helps, but here it is obvious, i.e. we are not changing other parts of the name or grouping different flags into a new one or things like that.

Is it desirable to keep -Zno-jump-tables for a period of time?

I think it is fine either way for us.

If the old flag isn't there, we may get a kernel build error here in this PR, in which case I can give you a commit to fix it.

[pmur]

I assume you mean -C for the latter, i.e. we are going directly from -Zno-jump-tables to -Cjump-tables rather than one more step -- that is what the PR seems to do, right? Otherwise, we will need to support 3 names on the kernel side, which isn't great.

Yes. I've updated the report. The PR intentionally contains a commit to rename -Zno-jump-tables to -Zjump-tables=, but I think that detail is ultimately irrelevant. I don't think anyone wants to support 3 names.

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[tgross35]

It seems like this should be about ready, with some possible delta to docs. Nominated for discussion.

[lcnr]

r? @jieyouxu maybe?

[jieyouxu]

A few minor things, I'll start an FCP after these discussions.

View changes since this review

[jieyouxu]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[arielb1]

Should this involve mitigation enforcement (rust-lang/rfcs#3855) as well?

Looks like a CFI-like option.

Why should this differ from stack protector in that respect?

[pmur]

Should this involve mitigation enforcement (rust-lang/rfcs#3855) as well?

Looks like a CFI-like option.

Why should this differ from stack protector in that respect?

I think there are valid scenarios where this could be used outside of potentially improving security.

A future improvement might add a secure option which prevents insecure jump tables (which, today seems to be equivalent to having no jump tables), and provide stronger guarantees at link time.

[jieyouxu]

I'll wait a bit for the mitigation enforcement discussions, seems like it's not super clear if this should be blocked on that effort (as a more "cohesive" package, so to speak).

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[tgross35]

@pmur I think you'll have to pick up Miguel's patch (comment) on your branch for this to go through, since that updates the rust-for-linux job to work with both flags

[pmur]

Please add ojeda@8781c65 to this branch and try again. I tested it locally. Thanks!

Ok, cherry-picked. Minor note, is that the preferred way of bringing in others' patches to a PR?

[tgross35]

@bors2 try jobs=x86_64-rust-for-linux

Ok, cherry-picked. Minor note, is that the preferred way of bringing in others' patches to a PR?

It doesn't come up too much but that is what I usually do. For one-off patches, it can also be convenient to add .patch and do curl https://github.com/ojeda/rust/commit/8781c65fd2083b47b9d38fe6b2cf6f6d720bde6c.patch | git am so you don't need to do a full fork checkout.

[rust-bors]

☀️ Try build successful (CI)
Build commit: c65a7f4 (c65a7f4b34031f26fca4da297424e8540a0fd9ef, parent: 1f880d9a1f4a331f1873829401e9d35fcfab2e36)

[rust-timer]

Queued c65a7f4 with parent 1f880d9, future comparison URL.
There are currently 0 preceding artifacts in the queue.
It will probably take at least ~1.1 hours until the benchmark run finishes.

[tgross35]

No idea why it queued a perf run there.

@bors r=wesleywiser

[bors]

📌 Commit fd11125 has been approved by wesleywiser

It is now in the queue for this repository.