Segmentation fault in /usr/bin/arm-linux-gnueabi-ld.bfd when cross-compiling with clang-10 using LTO

Hello,

For a project I'm working on, I have prepared an Ubuntu 20.04 chroot environment using debootstrap:

# lsb_release -a
LSB Version: core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal

In this environment I have installed various compilers and cross-compilers, in order to build a couple of open-source software packages for x86, amd64, arm and aarch64. When cross-compiling coreutils-3.82 for arm using clang-10 and -flto -fsanitize=cfi, I get the following crash (instructions on how to reproduce are given later on):

# gdb /software/bin/arm-linux-gnueabi-clang-10
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
...
(gdb) set follow-fork-mode child
(gdb) run -target armv7-linux-gnueabi -I /usr/arm-linux-gnueabi/include -O2 -flto -fsanitize=cfi -fvisibility=default -Wl,--as-needed -target armv7-linux-gnueabi -L /usr/arm-linux-gnueabi/lib -flto -fsanitize=cfi -o src/chroot src/chroot.o src/libver.a lib/libcoreutils.a lib/libcoreutils.a
Starting program: /software/bin/arm-linux-gnueabi-clang-10 -target armv7-linux-gnueabi -I /usr/arm-linux-gnueabi/include -O2 -flto -fsanitize=cfi -fvisibility=default -Wl,--as-needed -target armv7-linux-gnueabi -L /usr/arm-linux-gnueabi/lib -flto -fsanitize=cfi -o src/chroot src/chroot.o src/libver.a lib/libcoreutils.a lib/libcoreutils.a
...
Thread 2.1 "ld" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7c90100 (LWP 1132)]
elf32_arm_output_plt_map_1 (osi=osi@entry=0x7fffffffdad0, is_iplt_entry_p=is_iplt_entry_p@entry=1, arm_plt=0x2e3174706f74656f,
    root_plt=<optimized out>) at ../../bfd/elf32-arm.c:17986
17986 ../../bfd/elf32-arm.c: No such file or directory.
(gdb) bt
#0 elf32_arm_output_plt_map_1 (osi=osi@entry=0x7fffffffdad0, is_iplt_entry_p=is_iplt_entry_p@entry=1, arm_plt=0x2e3174706f74656f,
    root_plt=<optimized out>) at ../../bfd/elf32-arm.c:17986
#1 0x00007ffff7f1ebf6 in elf32_arm_output_arch_local_syms (output_bfd=<optimized out>, info=<optimized out>, flaginfo=<optimized out>,
    func=<optimized out>) at ../../bfd/elf32-arm.c:18447
#2 0x00007ffff7f57c7e in bfd_elf_final_link (abfd=abfd@entry=0x55555567eef0, info=info@entry=0x55555560f780 <link_info>)
    at ../../bfd/elflink.c:12406
#3 0x00007ffff7f28b1b in elf32_arm_final_link (abfd=0x55555567eef0, info=0x55555560f780 <link_info>) at ../../bfd/elf32-arm.c:13799
#4 0x000055555557850f in ldwrite () at ../../ld/ldwrite.c:545
#5 0x0000555555560469 in main (argc=<optimized out>, argv=<optimized out>) at ../../ld/ldmain.c:460
(gdb) x/10i $pc
=> 0x7ffff7f1e520 <elf32_arm_output_plt_map_1>: cmpq $0xffffffffffffffff,(%rdx)
   0x7ffff7f1e524 <elf32_arm_output_plt_map_1+4>: je 0x7ffff7f1e760 <elf32_arm_output_plt_map_1+576>
   0x7ffff7f1e52a <elf32_arm_output_plt_map_1+10>: push %r15
   0x7ffff7f1e52c <elf32_arm_output_plt_map_1+12>: push %r14
   0x7ffff7f1e52e <elf32_arm_output_plt_map_1+14>: push %r13
   0x7ffff7f1e530 <elf32_arm_output_plt_map_1+16>: push %r12
   0x7ffff7f1e532 <elf32_arm_output_plt_map_1+18>: push %rbp
   0x7ffff7f1e533 <elf32_arm_output_plt_map_1+19>: mov %rdi,%rbp
   0x7ffff7f1e536 <elf32_arm_output_plt_map_1+22>: push %rbx
   0x7ffff7f1e537 <elf32_arm_output_plt_map_1+23>: sub $0x8,%rsp
(gdb) i r rdx
rdx 0x2e3174706f746567 3328569625858565479
(gdb) x/16bx $rdx
0x2e3174706f746567: Cannot access memory at address 0x2e3174706f746567

Notice how $rdx has been overwritten with the value "getopt1." :-)

To reproduce, download coreutils-3.82 and extract it, say, under /tmp.

Next, create the following symbolic links (I do this because afaik it's an alternative to specifying -triplet in CFLAGS, CXXFLAGS and LDFLAGS):

# ls -la /software/bin/arm-linux-gnueabi-*-10
lrwxrwxrwx 1 root root 19 May 30 17:07 /software/bin/arm-linux-gnueabi-clang++-10 -> /usr/bin/clang++-10
lrwxrwxrwx 1 root root 17 May 30 17:07 /software/bin/arm-linux-gnueabi-clang-10 -> /usr/bin/clang-10
lrwxrwxrwx 1 root root 21 May 30 17:07 /software/bin/arm-linux-gnueabi-clang-cpp-10 -> /usr/bin/clang-cpp-10

Then, from within /tmp/coreutils-3.82:

# mkdir build
# cd build
# ../configure --host=arm-linux-gnueabi \
    CC="/software/bin/arm-linux-gnueabi-clang-10" \
    CFLAGS="-I /usr/arm-linux-gnueabi/include -O2 -flto -fsanitize=cfi -fvisibility=default" \
    CXX="/software/bin/arm-linux-gnueabi-clang++-10" \
    CXXFLAGS="-I /usr/arm-linux-gnueabi/include -O2 -flto -fsanitize=cfi -fvisibility=default" \
    CPP="/software/bin/arm-linux-gnueabi-clang-cpp-10" \
    CPPFLAGS="-I /usr/arm-linux-gnueabi/include" \
    LDFLAGS="-L /usr/arm-linux-gnueabi/lib -flto -fsanitize=cfi" \
    RANLIB="llvm-ranlib-10" \
    AR="llvm-ar-10"
# make

A couple of minutes later the build process will fail with a segmentation fault. To see the faulting command:

# make V=1
...

/software/bin/arm-linux-gnueabi-clang-10 -I /usr/arm-linux-gnueabi/include -O2 -flto -fsanitize=cfi -fvisibility=default -Wl,--as-needed -L /usr/arm-linux-gnueabi/lib -flto -fsanitize=cfi -o src/chroot src/chroot.o src/libver.a lib/libcoreutils.a lib/libcoreutils.a
clang: error: unable to execute command: Segmentation fault (core dumped)

After installing binutils-arm-linux-gnueabi-dbg, gdb can be used, as shown above, to examine the stacktrace.

# apt-cache policy binutils-arm-linux-gnueabi
binutils-arm-linux-gnueabi:
  Installed: 2.34-6ubuntu1.1
  Candidate: 2.34-6ubuntu1.1
  Version table:
 *** 2.34-6ubuntu1.1 500
        500 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages
        500 http://archive.ubuntu.com/ubuntu focal-security/universe amd64 Packages
        100 /var/lib/dpkg/status
     2.34-6ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages