[Bug 1938095] [NEW] Segmentation fault in /usr/bin/arm-linux-gnueabi-ld.bfd when cross-compiling with clang-10 using LTO
Chariton Karamitas
1938095 at bugs.launchpad.net
Mon Jul 26 21:54:09 UTC 2021
Public bug reported:
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 at entry=0x7fffffffdad0, is_iplt_entry_p=is_iplt_entry_p at 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 at entry=0x7fffffffdad0, is_iplt_entry_p=is_iplt_entry_p at 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 at entry=0x55555567eef0, info=info at 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
** Affects: binutils (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1938095
Title:
Segmentation fault in /usr/bin/arm-linux-gnueabi-ld.bfd when cross-
compiling with clang-10 using LTO
Status in binutils package in Ubuntu:
New
Bug description:
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 at entry=0x7fffffffdad0, is_iplt_entry_p=is_iplt_entry_p at 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 at entry=0x7fffffffdad0, is_iplt_entry_p=is_iplt_entry_p at 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 at entry=0x55555567eef0, info=info at 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1938095/+subscriptions
More information about the foundations-bugs
mailing list