[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200316175428.GV11469@brightrain.aerifal.cx>
Date: Mon, 16 Mar 2020 13:54:28 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: armv7-m musl 1.2.0 toolchain crash
On Mon, Mar 16, 2020 at 04:41:17PM +1100, Patrick Oppenlander wrote:
> 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.
Can you clarify if the change is that the toolchain is built against
musl 1.2.0 and now malfunctioning, or trying to link to musl 1.2.0 and
now malfunctioning? Those are very different and it's not clear which.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
