Rust 1.56 injected a valgrind incompatibility for Linux/AAarch64

[pnkfelix]

Code

I tried this code:

fn main() { let _n = std::time::Instant::now(); }

and ran it under valgrind.

I expected to see this happen: Successful program run with 0 errors from valgrind.

Instead, this happened:

$ valgrind ./target/debug/instant
==11772== Memcheck, a memory error detector
==11772== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11772== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==11772== Command: ./target/debug/instant
==11772==
ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0xC87F2D89
disInstr(arm64): 1100'1000 0111'1111 0010'1101 1000'1001
==11772== valgrind: Unrecognised instruction at address 0x11ffa4.
==11772==    at 0x11FFA4: atomic_umax<u128> (atomic.rs:2574)
==11772==    by 0x11FFA4: fetch_max (atomic.rs:1996)
==11772==    by 0x11FFA4: monotonize (monotonic.rs:91)
==11772==    by 0x11FFA4: monotonize (monotonic.rs:5)
==11772==    by 0x11FFA4: std::time::Instant::now (time.rs:270)
==11772==    by 0x10EB77: instant::main (main.rs:1)

Version it worked on

It most recently worked on: Rust 1.55

Version with regression

rustc --version --verbose:

rustc 1.56.0 (09c42c458 2021-10-18)
binary: rustc
commit-hash: 09c42c45858d5f3aedfa670698275303a3d19afa
commit-date: 2021-10-18
host: aarch64-unknown-linux-gnu
release: 1.56.0
LLVM version: 13.0.0

I also narrowed it down to which nightly injected the bug:

ubuntu@ip-172-31-93-250:~/instant$ cargo +nightly-2021-08-20 build
   Compiling instant v0.1.0 (/home/ubuntu/instant)
    Finished dev [unoptimized + debuginfo] target(s) in 0.66s
ubuntu@ip-172-31-93-250:~/instant$ valgrind ./target/debug/instant
==14475== Memcheck, a memory error detector
==14475== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==14475== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==14475== Command: ./target/debug/instant
==14475==
==14475==
==14475== HEAP SUMMARY:
==14475==     in use at exit: 0 bytes in 0 blocks
==14475==   total heap usage: 9 allocs, 9 frees, 1,977 bytes allocated
==14475==
==14475== All heap blocks were freed -- no leaks are possible
==14475==
==14475== For lists of detected and suppressed errors, rerun with: -s
==14475== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
ubuntu@ip-172-31-93-250:~/instant$ cargo +nightly-2021-08-21 build
   Compiling instant v0.1.0 (/home/ubuntu/instant)
    Finished dev [unoptimized + debuginfo] target(s) in 0.67s
ubuntu@ip-172-31-93-250:~/instant$ valgrind ./target/debug/instant
==14502== Memcheck, a memory error detector
==14502== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==14502== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==14502== Command: ./target/debug/instant
==14502==
ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0xC87F2D89
disInstr(arm64): 1100'1000 0111'1111 0010'1101 1000'1001
==14502== valgrind: Unrecognised instruction at address 0x11f6a0.
==14502==    at 0x11F6A0: atomic_umax<u128> (atomic.rs:2574)
==14502==    by 0x11F6A0: fetch_max (atomic.rs:1996)
==14502==    by 0x11F6A0: monotonize (monotonic.rs:91)
==14502==    by 0x11F6A0: monotonize (monotonic.rs:5)
==14502==    by 0x11F6A0: std::time::Instant::now (time.rs:251)
==14502==    by 0x10E9F3: instant::main (main.rs:1)

which makes sense, because I believe this was injected by PR #83093

(The above transcript includes an invocation of valgrind, v 3.15.0, that is not the latest. But I did a build of 3.18 and reproduced the same bug there as well.)

[pnkfelix]

My current hypothesis is that this is a bug entirely on the valgrind side. I reached out to the valgrind developers, and they floated a few hypotheses. E.g. that we might not be doing sufficient CPU detection on our side before going down code paths with instructions that valgrind does not yet handle. But they also said that they were mystified that we were encountering this.

In the meantime, here is the corresponding bug that I filed on the valgrind side: https://bugs.kde.org/show_bug.cgi?id=444399

(I believe the valgrind developers will be investigating it more in the next few days.)

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-high

[hkratz]

Just to simplify the code, as the original example does no longer reproduce for me on nightly.

This:

let _x = AtomicU128::new(3).fetch_max(7, Relaxed);

compiles with current nightly on aarch64-unknown-linux-gnu to:

atomictest::main:
 sub     sp, sp, #16
 mov     w9, #3
 mov     x8, sp
 stp     x9, xzr, [sp]
 mov     w9, #7
.LBB5_1:
 ldxp    x10, x11, [x8]
 cmp     x10, #7
 cset    w12, hi
 cmp     x11, #0
 cset    w13, ne
 csel    w12, w12, w13, eq
 cmp     w12, #0
 csel    x11, x11, xzr, ne
 csel    x10, x10, x9, ne
 stxp    w12, x10, x11, [x8]
 cbnz    w12, .LBB5_1
 add     sp, sp, #16
 ret

Valgrind complains about opcode 1100'1000 0111'1111 0010'1101 1000'1001, which is ldxp (see ARM reference maual page C6-1199). AFAICS ldxp is part of the normal ARMv8.0 instruction set, no target features required.

[hkratz]

Added a C++ reproducer to the valgrind bug report: https://bugs.kde.org/show_bug.cgi?id=444399#c3

[hkratz]

Should this be closed now that it has been acknowledged to be a shortcoming of valgrind: https://bugs.kde.org/show_bug.cgi?id=444399#c5?

[pnkfelix]

Closing as assumed fixed with https://sourceware.org/git/?p=valgrind.git;a=commit;h=530df882b8f60ecacaf2b9b8a719f7ea1c1d1650