regression/thumb: memcmp is missing from compiler-builtins

[japaric]

STR

$ cargo generate --git https://github.com/rust-embedded/cortex-m-quickstart --name app
$ cd app
$ # modify main
$ cat src/main.rs

#![no_std]
#![no_main]

extern crate panic_halt;

use cortex_m::asm;
use cortex_m_rt::entry;

#[entry]
fn main() -> ! {
    let x: &[i32] = &[0, 1, 2, 3];
    let y: &[i32] = &[0, 1, 2, 3, 4];

    if x == y {
        asm::nop();
    }

    loop {}
}

$ cargo build
error: linking with `rust-lld` failed: exit code: 1
(..)
  = note: rust-lld: error: undefined symbol: memcmp

Meta

$ rustc -V
rustc 1.32.0-nightly (f4a421ee3 2018-12-13)

---

It seems that all the unmangled mem* symbols are gone in newer nightlies.

$ nm -C $(rustc --print sysroot)/lib/rustlib/thumbv7m-none-eabi/lib/libcompiler_builtins-*.rlib | grep mem
00000001 W __aeabi_memclr
00000001 W __aeabi_memclr4
00000001 W __aeabi_memclr8
00000001 W __aeabi_memcpy
00000001 W __aeabi_memcpy4
00000001 W __aeabi_memcpy8
00000001 W __aeabi_memmove
00000001 W __aeabi_memmove4
00000001 W __aeabi_memmove8
00000001 W __aeabi_memset
00000001 W __aeabi_memset4
00000001 W __aeabi_memset8
00000001 T compiler_builtins::mem::memcmp
00000001 T compiler_builtins::mem::memcpy
00000001 T compiler_builtins::mem::memset
00000001 T compiler_builtins::mem::memmove

$ # older nightly
$ nm -C $(rustc +nightly-2018-12-08 --print sysroot)/lib/rustlib/thumbv7m-none-eabi/lib/libcompiler_builtins-*.rlib | grep mem
00000001 W __aeabi_memclr
00000001 W __aeabi_memclr4
00000001 W __aeabi_memclr8
00000001 W __aeabi_memcpy
00000001 W __aeabi_memcpy4
00000001 W __aeabi_memcpy8
00000001 W __aeabi_memmove
00000001 W __aeabi_memmove4
00000001 W __aeabi_memmove8
00000001 W __aeabi_memset
00000001 W __aeabi_memset4
00000001 W __aeabi_memset8
00000001 T memcmp
00000001 T memcpy
00000001 T memmove
00000001 T memset

I think it's fine to remove memcpy, memmove and memset because llvm uses the aeabi counterparts but memcmp is required.

cc @alexcrichton

[alexcrichton]

Sorry for the breakage! I think I've found the issue (almost fure sure a regression from #56092), and am testing out a fix locally

[alexcrichton]

Ok should be fixed in #56825!

[japaric]

This appears to be fixed in the latest nightly.