You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gary proposed reading DWARF instead and wrote a quick Rust script for it via object and gimli, though DWARF would need to be available or generated on the fly just for that (and we cannot commit a fixed list since the kernel config may change and we support several Rust versions and so on): https://gist.github.com/nbdd0121/449692570622c2f46a29ad9f47c3379a.
It could perhaps be a flag like -Cunsigned-char, or a "target modifier" instead, if those (RFC) come to fruition.
The kernel uses it (unconditionally) since commit 3bc753c ("kbuild: treat char as always unsigned") (v6.2).
The kernel will use a custom FFI mapping (kernel::ffi:: instead of core::ffi::) everywhere (i.e. for bindgen-generated code as well as manually written code), so we have a workaround for that part. However, things like CStr/c"" still use core::ffi::'s definition, so it would still be nice to match it.
This is not critical now, since we mainly support only LLVM=1 builds so far, but eventually we will want to match the C side for GCC builds when those become non-experimental.
Showing type aliases (perhaps in addition to resolved types) in error messages, potentially manually tagging the cases with sometimes like #[own_name].
Some kernel developers want to build Linux under macOS, but the kernel does not support that (the macOS support is maintained out-of-tree). So they may need something like this to minimize the differences with upstream. There may be other possible solutions (e.g. using symlinks, if that works, but it would require knowing the names in general). Perhaps this could help other projects to be ported to macOS too.
Low priority (we will likely not use them in the end)
--check mode / --emit=check.
Like cargo check, but for rustc.
cargo check appears to do --emit=dep-info,metadata, but that would not be needed for the leaves.
Currently, the best approximation appears to be --emit=metadata, but it would be nice to have a way that reduces the work to the minimum, at least avoiding to emit the metadata and temporaries.
--emit=metadata=/dev/null does not appear to work due to the generated temporaries (and -Ztemps-dir does not seem to change that).
Use case: some tests (e.g. in upstream Rust: the warning-free builds of core and alloc under no_global_oom_handling in rustc) and faster development (it could also be part of a dev-mode in the kernel, which could include other changes like disabling the missing documentation warning).
Done (stabilized, fixed, not needed anymore, etc.)
-Zpatchable-function-entry support (GCC's and Clang's -fpatchable-function-entry), as well as the patchable_function_entry function attribute.
Moved into the main list since it got implemented.
-Zregparm=3 and -Zreg-struct-return.
Moved to the main list, since they got issued a tracking issue and are being implemented.
GCC's/Clang's -mregparm=3 and -freg-struct-return.
Used by: x86 (i.e. 32-bit).
-Zregparm=3 could have been just a bit of plumbing in rustc, but it turns out Clang is the one that has the logic to decide the registers, which then get marked in LLVM IR, and thus rustc needs to duplicate the logic (or moving it into LLVM and then wait for a release).
-Zreg-struct-return can be skipped if a target.json is used (abi_return_struct_as_int in target spec).
Commit: e852f31 ("[PATCH] Add CONFIG for -mregparm=3") (in history.git).
Commit: 2516512 ("[PATCH] x86: add -freg-struct-return to CFLAGS").
Layout randomization.
-Zrandomize-layout (and -Zlayout-seed=<seed>) were implemented, though the use case of the MCP was debugging (e.g. detecting invalid layout assumptions), rather than security (which the kernel uses under some configurations -- see CONFIG_RANDSTRUCT*).
rustc 1.76 (beta) warns about non-recursive invocation from Make.
rustc may document that it may always take advantage of the jobserver (e.g. for backend and eventually frontend parallelism), and thus users should always call rustc as recursive from Make.
Note: there is the "A-rust-for-linux" label in the
rust
repository: https://github.com/rust-lang/rust/labels/A-rust-for-linux.Features that we would like to see
Required (we almost certainly want them)
x86's
CONFIG_SPECULATION_MITIGATIONS
.rustc
.CONFIG_RETPOLINE
: Clang's-mretpoline-external-thunk
and GCC's-mindirect-branch=thunk-extern -mindirect-branch-register
. Old issue (when the target feature was+retpoline
: Please add retpoline support. rust-lang/rust#54637). Passing the target features in the target specification file works, but we cannot use-Ctarget-feature=
due to the warnings -- see Retpoline support inrustc
(target features or dedicated flags) rust-lang/rust#116852.CONFIG_RETHUNK
: Clang's/GCC's-mfunction-return=thunk-extern
. See Tracking Issue for-Zfunction-return
rust-lang/rust#116853. PR: Add-Zfunction-return={keep,thunk-extern}
option rust-lang/rust#116892.CONFIG_SLS
: Clang's/GCC's-mharden-sls=all
. Passing the target features in the target specification file works, but we cannot use-Ctarget-feature=
due to the warnings -- see SLS support inrustc
(target features or dedicated flags) rust-lang/rust#116851.Export (somehow) a list of all
noreturn
symbols.objtool
needs a list of functions that do not return.rustc
could emit somewhere (e.g. a file, via--emit=noreturns
) a list ofnoreturn
symbols. In particular, Peter suggests using a section: https://lore.kernel.org/rust-for-linux/20240806202217.GZ37996@noisy.programming.kicks-ass.net/object
andgimli
, though DWARF would need to be available or generated on the fly just for that (and we cannot commit a fixed list since the kernel config may change and we support several Rust versions and so on): https://gist.github.com/nbdd0121/449692570622c2f46a29ad9f47c3379a.-funsigned-char
(GCC, Clang).-Cunsigned-char
, or a "target modifier" instead, if those (RFC) come to fruition.kernel::ffi::
instead ofcore::ffi::
) everywhere (i.e. forbindgen
-generated code as well as manually written code), so we have a workaround for that part. However, things likeCStr
/c""
still usecore::ffi::
's definition, so it would still be nice to match it.-fmin-function-alignment
(GCC, Clang does not support it) /-falign-functions
(GCC, Clang)-falign-functions=0
, only for a few CPUs).-fmin-function-alignment
and Clang's-falign-functions
, i.e. align all functions, including cold functions.feature(fn_align)
, but we need to do it globally.#[repr(align(...))]
on function items (fn_align) rust-lang/rust#82232.-Cmin-function-alignment
/-Calign-functions
support inrustc
rust-lang/rust#128830.-falign-loops=1
, i.e. not aligned (GCC, Clang).-falign-loops=0
, only for a few CPUs).-Calign-loops=1
support inrustc
rust-lang/rust#128832.-mpreferred-stack-boundary
(GCC, Clang does not support it) /-mstack-alignment
(GCC does not support it, Clang).-mpreferred-stack-boundary=3
,-mstack-alignment=8
).-mpreferred-stack-boundary=2
,-mstack-alignment=4
).-Cstack-alignment
/-Cpreferred-stack-boundary
support inrustc
rust-lang/rust#128833.-mskip-rax-setup
(GCC, Clang).Nice to have (not critical, we could workaround if needed, etc.)
-falign-jumps=1
, i.e. not aligned (GCC, Clang does not support it).-falign-jumps=0
, only for a few CPUs).-Calign-jumps=1
support inrustc
rust-lang/rust#128831.LLVM=1
builds so far, but eventually we will want to match the C side for GCC builds when those become non-experimental.Showing type aliases (perhaps in addition to resolved types) in error messages, potentially manually tagging the cases with sometimes like
#[own_name]
.Arc<T> = ARef<WithRef<T>>
and would improve readability of messages around e.g.Mutex<T> = Lock<T, MutexBackend>
.A way to skip the existing bypass of lints that come from foreign crates.
-Dunsafe_op_in_unsafe_fn
in generated code by proc macros.-masm=
equivalent (i.e. the ability to configure the assembly syntax default).MSRV for
rustc
, similar to Cargo's and Clippy ones (--msrv=version
).--hint-msrv=version
option so the compiler can take MSRV into account when linting rust-lang/compiler-team#772 (accepted).Ability to load
.so
libraries under macOS.--extern mycrate=path/to/my/crate/with/random.suffix
fails with "file name should be lib*.rlib or lib*.so" rust-lang/rust#131720.Flag output.
Low priority (we will likely not use them in the end)
--check
mode /--emit=check
.cargo check
, but forrustc
.cargo check
appears to do--emit=dep-info,metadata
, but that would not be needed for the leaves.--emit=metadata
, but it would be nice to have a way that reduces the work to the minimum, at least avoiding to emit the metadata and temporaries.--emit=metadata=/dev/null
does not appear to work due to the generated temporaries (and-Ztemps-dir
does not seem to change that).core
andalloc
underno_global_oom_handling
inrustc
) and faster development (it could also be part of a dev-mode in the kernel, which could include other changes like disabling the missing documentation warning).core
underno_global_oom_handling
rust-lang/rust#110652.Done (stabilized, fixed, not needed anymore, etc.)
-Zpatchable-function-entry
support (GCC's and Clang's-fpatchable-function-entry
), as well as thepatchable_function_entry
function attribute.-Zregparm=3
and-Zreg-struct-return
.-mregparm=3
and-freg-struct-return
.-Zregparm=3
could have been just a bit of plumbing inrustc
, but it turns out Clang is the one that has the logic to decide the registers, which then get marked in LLVM IR, and thusrustc
needs to duplicate the logic (or moving it into LLVM and then wait for a release).-Zreg-struct-return
can be skipped if atarget.json
is used (abi_return_struct_as_int
in target spec).-Zregparm
rust-lang/rust#131749.-Zreg-struct-return
support inrustc
rust-lang/rust#116973.-Zregparm=3
support inrustc
rust-lang/rust#116972.history.git
).Layout randomization.
-Zrandomize-layout
(and-Zlayout-seed=<seed>
) were implemented, though the use case of the MCP was debugging (e.g. detecting invalid layout assumptions), rather than security (which the kernel uses under some configurations -- seeCONFIG_RANDSTRUCT*
).-Z randomize-layout
flag rust-lang/compiler-team#457.-Zrandomize-layout
flag to better detect code that rely on unspecified behavior related to memory layout rust-lang/rust#77316.-Z randomize-layout
rust-lang/rust#106764.-Z randomize-layout
rust-lang/rust#91932.CET (
-Zcf-protection=branch
).KCFI (
-Zsanitizer=kcfi
&-Zsanitizer-cfi-normalize-integers
).x86's
CONFIG_X86_KERNEL_IBT
support (-Zcf-protection=branch -Zno-jump-tables
).-fcf-protection=branch -fno-jump-tables
.Make
debug_triple
depend ontarget.json
file content rather than file path.Diagnostics for
-D
flags make it slightly harder to allow vs.#![deny(...)]
.-D
flags make it slightly harder to allow vs.#![deny(...)]
rust-lang/rust#114030.help:
line): Add an allow attribute suggestion along with the implied by suggestion rust-lang/rust#114089 (1.74)..comment
section support..comment
section like GCC/Clang (!llvm.ident
) rust-lang/rust#97550 (1.73).rustc_codegen_gcc
): subtree update cg_gcc 2023/11/17 rust-lang/rust#118068 (1.76).arm64: shadow call stack (SCS) support.
-Zsanitizer=shadow-call-stack
in the builtin target): Shadow call stack should be supported onaarch64-unknown-none
rust-lang/rust#121972.-Ctarget-feature=+reserve-x18
to avoid warning): Compiler does not recognize thereserve-x18
target feature rust-lang/rust#121970.-Ctarget-feature=+reserve-x18
to avoid warning): Addreserve-x18
target feature for aarch64 rust-lang/rust#124323.-Zfixed-x18
flag): Add-Zfixed-x18
rust-lang/rust#124655 (1.80).-Zfixed-x18
rust-lang/compiler-team#748.KASAN.
-Zsanitizer=kernel-address
is being implemented.kernel-address
sanitizer support for freestanding targets rust-lang/rust#99679.Bugs that we would like to see fixed
Required (we almost certainly want them)
-Dwarnings
(or include a way to control whether they are errors).target json file contains unused fields
unaffected by-Dwarnings
rust-lang/rust#91262.-Dwarnings
to cover all warnings rust-lang/compiler-team#473.Nice to have (probably not critical, we could workaround if needed, etc.)
Finish
unreachable_pub
lint implementation.unreachable_pub
got easily confused by multiple items in a singlepub use ...
statement rust-lang/rust#64762.rustc_privacy
torustc_resolve
rust-lang/rust#82064.--emit=dep-info
+-Zunpretty=expanded
emits output.--emit=dep-info
+-Zunpretty=expanded
emits output rust-lang/rust#93201.Missed optimization (
to_result
discussion).Missed optimization (wrapping "raw generated
enum
s into cleaner ones).enum
s rust-lang/rust#116272.Low priority (we will likely not use them in the end)
rustc
warns when finding an unknown jobserver style.rustc
(or users could force an older jobserver style).rustc
warns when finding an unknown jobserver style rust-lang/rust#120532.Done (stabilized, fixed, or not needed anymore, etc.)
creader: Host crate loaded twice produces different
CrateNum
s if host != target.CrateNum
s if host != target rust-lang/rust#56935.Skip linking if it is not required.
ICE when proc macro panics if compiled with
-Cpanic=abort
.-Cpanic=abort
rust-lang/rust#82320.Set
dso_local
for hidden, private and local items.Set
dso_local
for more items.Add back support for
inline
stack-probes
.Strange
-Zunpretty=expanded
behavior withglobal_asm!
.-Zunpretty=expanded
output withglobal_asm!
loses semicolon thus cannot be formatted rust-lang/rust#101047.-Zunpretty=expanded
output may not containglobal_asm!
depending on comments/whitespace/... rust-lang/rust#101051.global_asm
macro pretty printing rust-lang/rust#101369.The
x86_64-unknown-none-linuxkernel
target is not actually used.ARM64: Fix some issues with folded AArch64 features.
Ensure 128-bit types from the C side (
__int128_t
,__uint128_t
) are usable for architectures that need it.i128
/u128
match the ABI of the C ones, and that should remain the case thanks to Create optionally-available __int128 typedefs and use them for ARM64 definitions. rust-lang/libc#2719.i128
/u128
from theimproper_ctypes
lint rust-lang/lang-team#255..eh_frame
section emitted forkernel.o
(debug assertions enabled,rustc
>= 1.70.0)..eh_frame
section emitted forkernel.o
(debug assertions enabled,rustc
>= 1.70.0) #1012..eh_frame
from being emitted for-C panic=abort
rust-lang/rust#112403 (1.72)..eh_frame
section emitted forrust_echo_server.o
..eh_frame
section emitted forrust_echo_server.o
#1016.-Zunpretty=expanded
does not emitdep-info
anymore (1.68 -> 1.69).-Zunpretty=expanded
does not emitdep-info
anymore (1.68 -> 1.69) rust-lang/rust#112898.-Zunpretty
rust-lang/rust#114476 (1.73).#[expect(dead_code)]
does not behave identically to#[allow(dead_code)]
.#[expect(dead_code)]
does not behave identically to#[allow(dead_code)]
rust-lang/rust#114557.#[expect]
the same way#[allow]
is with thedead_code
lint rust-lang/rust#114710 (1.73).1.74 ICE.
rustc
1.76 (beta) warns about non-recursive invocation from Make.rustc
may document that it may always take advantage of the jobserver (e.g. for backend and eventually frontend parallelism), and thus users should always callrustc
as recursive from Make.rustc
insidemake -j2
warns (regression from 1.75.0) rust-lang/rust#120515.The last
--jobserver-auth
flag should be used like the GNU Make manual asks to (jobserver
crate, used byrustc
).--jobserver-auth
flag should be used rust-lang/jobserver-rs#66.jobserver
): fix: last--jobserver-auth
wins rust-lang/jobserver-rs#67.rustc
should disable the jobserver if file descriptors are negative like the GNU Make manual asks to.rustc
calls as recursive.rustc
insidemake -j2
warns (regression from 1.75.0) rust-lang/rust#120515.jobserver
): disable jobserver on unix, if file descriptors are negative rust-lang/jobserver-rs#68.ICE on
rustc 1.79.0-beta.4 (a26981974 2024-05-10)
when compilingcore.o
.RUSTC_BOOTSTRAP=1 rustc --edition=2021 -Csymbol-mangling-version=v0 --cfg no_fp_fmt_parse --crate-type rlib library/core/src/lib.rs --sysroot=/dev/null
.f16
andf128
rust-lang/rust#123816 (1.79).f16
/f128
fallback code is not getting inlined rust-lang/rust#125229.#[inline]
to floatDebug
fallback used bycfg(no_fp_fmt_parse)
rust-lang/rust#125252 (1.79).rustc 1.79.0-beta.7 (d9e85b56e 2024-05-25)
.The text was updated successfully, but these errors were encountered: