## Features that we would like to see ### Required (we almost certainly want them) - [ ] If a new approach for kCFI type IDs is introduced, then a way to query/set the kind being used is needed. + The mechanism used in both `rustc` and Clang need to agree, thus we need to ensure they are the same. + If a single approach is supported (rather than supporting several at the same time), then it may be hard to mix and match `rustc`/Clang versions. + PR (introducing a new approach): https://github.com/llvm/llvm-project/pull/117121. + PR (another approach): https://github.com/llvm/llvm-project/pull/121070. - [ ] Clarify that `--internalize` in `llvm-link` does what we want it to do for the inline helpers without full LTO approach. + PR: https://github.com/llvm/llvm-project/pull/170397. + Lore: https://lore.kernel.org/rust-for-linux/CAGSQo01=7YDfYzbjipNtsK8AzXciSpY+v53kAhh+oZ_QisAh4Q@mail.gmail.com/. - [ ] Supporting BTF for Rust with LTO by generating BTF directly instead of going through `pahole`. + PR (`--btf-merge` for `lld`): https://github.com/llvm/llvm-project/pull/183915. + PR (`-gbtf` for Clang, like GCC's): https://github.com/llvm/llvm-project/pull/183929. + Zulip: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/BTF.20generation.20in.20rustc.3F/near/577913877. - [ ] Allow inlining with `null_pointer_is_valid` mismatch. + PR: https://github.com/llvm/llvm-project/pull/190510. + Rust Zulip: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/Cross.20language.20inlining.20and.20-fno-delete-null-pointer-checks/near/583438139. ### Nice to have (not critical, we could workaround if needed, etc.) - [ ] Querying GCC-style inline assembly so that `bindgen` can translate it into Rust inline assembly. + Discourse: https://discourse.llvm.org/t/a-small-proposal-for-extraction-of-inline-assembly-block-information/86658. + PR: https://github.com/llvm/llvm-project/pull/143424. + Cc: @dingxiangfei2009. - [ ] LLVM emits a 64-bit division even when dividing a `u64` by a constant (e.g. `10`), which is a problem for e.g. 32-bit arm. + Issue: https://github.com/llvm/llvm-project/issues/37280. + Lore: https://lore.kernel.org/rust-for-linux/20250627123854.921704-1-jfalempe@redhat.com/. ### Low priority (we will likely not use them in the end) ### Done (stabilized, fixed, not needed anymore, etc.) --- ## Bugs that we would like to see fixed ### Required (we almost certainly want them) ### Nice to have (probably not critical, we could workaround if needed, etc.) ### Low priority (we will likely not use them in the end) ### Done (stabilized, fixed, or not needed anymore, etc.) - [x] LLVM miscompilation for `asm goto` with outputs. + Issue: https://github.com/llvm/llvm-project/issues/74483. + Issue: https://github.com/llvm/llvm-project/issues/110251. + PR: https://github.com/llvm/llvm-project/pull/131350 (21?).
Features that we would like to see
Required (we almost certainly want them)
If a new approach for kCFI type IDs is introduced, then a way to query/set the kind being used is needed.
rustcand Clang need to agree, thus we need to ensure they are the same.rustc/Clang versions.Clarify that
--internalizeinllvm-linkdoes what we want it to do for the inline helpers without full LTO approach.--internalizedescription llvm/llvm-project#170397.Supporting BTF for Rust with LTO by generating BTF directly instead of going through
pahole.--btf-mergeforlld): [lld][DebugInfo/BTF] Add BTF section merging and deduplication llvm/llvm-project#183915.-gbtffor Clang, like GCC's): [Clang][CodeGen] Add -gbtf: target-independent BTF emission for ELF targets llvm/llvm-project#183929.Allow inlining with
null_pointer_is_validmismatch.Nice to have (not critical, we could workaround if needed, etc.)
Querying GCC-style inline assembly so that
bindgencan translate it into Rust inline assembly.LLVM emits a 64-bit division even when dividing a
u64by a constant (e.g.10), which is a problem for e.g. 32-bit arm.Low priority (we will likely not use them in the end)
Done (stabilized, fixed, not needed anymore, etc.)
Bugs that we would like to see fixed
Required (we almost certainly want them)
Nice to have (probably not critical, we could workaround if needed, etc.)
Low priority (we will likely not use them in the end)
Done (stabilized, fixed, or not needed anymore, etc.)
asm gotowith outputs.-O0llvm/llvm-project#110251.