From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 6931 invoked from network); 18 Mar 2020 19:10:58 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 18 Mar 2020 19:10:58 -0000 Received: (qmail 13453 invoked by uid 550); 18 Mar 2020 19:10:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13435 invoked from network); 18 Mar 2020 19:10:52 -0000 Date: Wed, 18 Mar 2020 20:10:39 +0100 From: Szabolcs Nagy To: musl@lists.openwall.com Cc: Patrick Oppenlander Message-ID: <20200318191039.GQ14278@port70.net> Mail-Followup-To: musl@lists.openwall.com, Patrick Oppenlander References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [musl] armv7-m musl 1.2.0 toolchain crash * Patrick Oppenlander [2020-03-16 16:41:17 +1100]: > 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 this is likely fixed by this binutils commit: commit 73d5efd7e13ebd8fe87278224bc2ae777af3de52 Author: Alan Modra AuthorDate: 2019-11-21 08:57:00 +1030 Commit: Alan Modra CommitDate: 2019-11-21 21:08:30 +1030 ARM cmse_scan segfault This code in elf_link_add_object_symbols: ret = elf_add_dt_needed_tag (abfd, info, soname, add_needed); if (ret < 0) goto error_return; /* If we have already included this dynamic object in the link, just ignore it. There is no reason to include a particular dynamic object more than once. */ if (ret > 0) return TRUE; prevents a shared library from being loaded twice by ensuring that any library soname doesn't match the soname of one already loaded. This happens before sym_hashes are allocated, which leaves sym_hashes NULL. cmse_scan looks at library symbols, and when attempting to look up a global symbol will segfault if sym_hashes is zero. * elf32-arm.c (elf32_arm_size_stubs): Exclude dynamic library BFDs that have not been loaded. which was not backported to earlier release branches so only in 2.34. (old binutils had no cmse support so that should work too) > #1 0x00005555555de1e7 in elf32_arm_size_stubs > (output_bfd=0x555555788100, stub_bfd=0x55555579c8c0, > info=0x55555574c4a0 , group_size=1, > add_stub_section=0x5555555a9ecd , > layout_sections_again=0x5555555aa049 ) > 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