[Pkg-rust-maintainers] Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

[James Addison]

Package: rustc
Followup-For: Bug #973414
X-Debbugs-Cc: martin-eric.racine at iki.fi, fierelier at gmail.com, smcv at debian.org, rustc at packages.debian.org

I've been trying to track down 'NOPL' opcodes in Debian's i386 bookworm archive
and many of the affected cases appear Rust and/or LLVM-related.

The simplest way to repro a Rust example that I've found so far is to build
the src:rust-lscolors[1] package from source in an i386 bookworm environment,
and then to 'objdump -d' the resulting 'lscolors' binary to grep for 'nopl'.

During that investigation, I learned about the existence of this bug, because
it sounds similar (unsupported opcodes, Rust toolchain, i386).


On Fri, 10 Mar 2023 09:58:42 +0200, Éric wrote:
> It's just a hunch, but I don't think that this issue will be resolved
> until Debian switches to the Rust compiler that has been merged with
> GCC 13, since GCC tends to respect CPU flags across the board.

That might be true, but I'd like to hope that we might be able to do better, or
at least determine where the opcodes (division and nopl) are originating from.

Although I understand that Debian has a rustc patch[2] in place to adjust the
intended baseline, my current/next area of focus is going to be llvm-14.0.6
because as Éric notes, something doesn't seem to be functioning as intended.

In particular, one area to look at:

  https://github.com/llvm/llvm-project/blob/llvmorg-14.0.6/clang/lib/Driver/ToolChains/Arch/X86.cpp#L25-L70

(with credit to an upstream thread[3] where Fierelier is also chasing this)


[1] - https://packages.debian.org/source/bookworm/rust-lscolors

[2] - https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/patches/d-rustc-i686-baseline.patch/

[3] - https://github.com/llvm/llvm-project/issues/61347