On Fri, Apr 14, 2023 at 7:12 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
>
> Not to mention how objtool will react to compiled rust code (has it
> already been tried?)
Rust uses LLVM, so it should be generally fine -- at least some of the
checks appear to work. For instance, I can trigger:
RUSTC L rust/kernel.o
rust/kernel.o: warning: objtool: .text+0x0: unreachable instruction
RUSTC [M] samples/rust/rust_minimal.o
samples/rust/rust_minimal.o: warning: objtool:
_R..._6kernel6Module4init+0x172: unreachable instruction
via a random instruction in the middle of nowhere in the former (with
`global_asm!`) and a jumped-over instruction in the latter (with
`asm!`).
Moreover, we were already getting warnings when rethunk / x86 IBT is
enabled (since we got `objtool` called for `vmlinux.o`), e.g.
vmlinux.o: warning: objtool: .rodata+0x18c58: data relocation to
!ENDBR: _R...IsWhitespaceEEB4_+0x0
vmlinux.o: warning: objtool: _R...into_foreign+0x5: 'naked' return
found in RETHUNK build
I can send the patch to run it for all Rust object files via
`$(cmd_objtool)`, unless you think it is a bad idea.
Having said that, tooling may indeed have issues, e.g. Arnaldo (Cc'd)
is improving `pahole` to avoid assumptions around struct layout like
field reordering (which Rust does by default).
Cheers,
Miguel
