Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Mar 2020 16:41:17 +1100
From: Patrick Oppenlander <patrick.oppenlander@...il.com>
To: musl@...ts.openwall.com
Subject: armv7-m musl 1.2.0 toolchain crash

After the update to musl 1.2.0 (1.1.24 was fine) ld crashes when
trying to link a C++ executable. C executables successfully link. The
toolchain was built as at commit
5086175f29021e3bebb7d9f5d83c4a796d96ebbd of musl-cross-make with the
following configuration:

TARGET = armv7m-linux-musleabihf
GCC_CONFIG += --with-cpu=cortex-m7  # easier than arch/fpu/tune
GCC_CONFIG += --enable-languages=c,c++
GCC_CONFIG += --disable-libquadmath --disable-decimal-float
GCC_CONFIG += --enable-default-pie
GCC_CONFIG += --enable-cxx-flags="-ffunction-sections"
MUSL_CONFIG += --enable-debug
COMMON_CONFIG += CFLAGS="-g0 -Os" CXXFLAGS="-g0 -Os"
COMMON_CONFIG += --disable-nls
COMMON_CONFIG += --with-debug-prefix-map=\$(CURDIR)=

Host compiler is arch linux gcc 9.3.0-1.

This results in a toolchain which does the following:
% cat test.c
int main() { return 0; }
% armv7m-linux-musleabi-gcc test.c
% armv7m-linux-musleabi-g++ test.c
collect2: fatal error: ld terminated with signal 11 [Segmentation
fault], core dumped
compilation terminated.

The crash is a null pointer dereference in ld here (sym_hashes is 0):

(gdb) bt
#0  cmse_scan (input_bfd=0x555555e3a110, htab=0x55555578a260,
out_attr=0x5555557885c0, sym_hashes=0x0,
cmse_stub_created=0x7fffffffd4c8)
    at ../../src_binutils/bfd/elf32-arm.c:6016
#1  0x00005555555de1e7 in elf32_arm_size_stubs
(output_bfd=0x555555788100, stub_bfd=0x55555579c8c0,
info=0x55555574c4a0 <link_info>, group_size=1,
    add_stub_section=0x5555555a9ecd <elf32_arm_add_stub_section>,
layout_sections_again=0x5555555aa049 <gldarm_layout_sections_again>)
    at ../../src_binutils/bfd/elf32-arm.c:6542
#2  0x00005555555aa43b in gldarmelf_linux_eabi_after_allocation () at
earmelf_linux_eabi.c:481
#3  0x00005555555a2351 in ldemul_after_allocation () at
../../src_binutils/ld/ldemul.c:76
#4  0x0000555555597a6d in lang_process () at ../../src_binutils/ld/ldlang.c:7693
#5  0x000055555559bce5 in main (argc=35, argv=0x7fffffffd8b8) at
../../src_binutils/ld/ldmain.c:441

Looks like a change in musl have exposed an ld bug.

Happy to provide more debugging if it helps.

Kind regards,

Patrick

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.