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

[James Addison]

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

The default behaviour of rustc to use static linking for output binaries could
be relevant to this bug.

Although I realize that the NOPL problem I'm tracking down isn't precisely the
issue originally reported here, both of them do relate to the way that the Rust
toolchain emits binaries.

On Fri, 24 Mar 2023 14:23:18 +0000, James wrote:
> 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'.

Since then, I've found that exporting RUSTFLAGS='-C prefer-dynamic' as an
environment variable during compilation of 'src:rust-lscolors' produces a
working output binary that is free from NOPL (non-i686) instructions.

That's not a precise way to confirm that the static linking is the problem, but
it does make it much more likely, I reckon.


So, roughly speaking:

  * I think that Debian's patched LLVM is correctly matched to the Debian i386
    baseline, and behaves as expected.

  * I think that Debian's patched rustc profile for i686 GNU/Linux (as
    mentioned by smcv) is also working as expected.

  * The existing compiled Rust stdlib libraries in Debian i386 contain some
    non-i686 opcodes.

  * Compiling statically-linked Rust libraries (the default) on Debian i386
    may include non-i686 opcodes such as those from the libstd-rust-dev
    package.


If that's the case, then one question is: why do those existing i386 packages
contain those opcodes?

  $ dpkg -L libstd-rust-dev | grep builtins
  /usr/lib/rustlib/i686-unknown-linux-gnu/lib/libcompiler_builtins-8e47f837ce9e5b67.rlib

  $ objdump -d /usr/lib/rustlib/i686-unknown-linux-gnu/lib/libcompiler_builtins-8e47f837ce9e5b67.rlib | grep -wc nopl
  31


(rebuilding them, and then rebuilding their Debian i386 Rust rdepends, should
I believe fix the problem if this theory holds)