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=-1.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,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 27018 invoked from network); 16 Mar 2020 05:41:47 -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; 16 Mar 2020 05:41:47 -0000 Received: (qmail 14249 invoked by uid 550); 16 Mar 2020 05:41:40 -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 14219 invoked from network); 16 Mar 2020 05:41:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FTAJTAHdphSA+mdWC5j7m6XkeSqEpCDSNvEt/z6cFZs=; b=EHeqPTe0x3HRhRxdF+GxgkMlF/l2fXELa2ynHBdcgS+BVukAKvn4rHI/lgwIldsZoA PD13fU+lqTZ7RKDHnl8X4k25IWED9GSb1V2qyxEY9W6bYv9LnJill2vMHj+AbglSIxGz b6nkkYwAjqpjZISTnILFRu5M0SSYEPJgZVCBLLOjHgDBP+NuvQokXg4kffZPpDIe/Xlh JErxCMMsuXqMyIePF62zVZy6uUZ6bkx9sdQDT1MCTXhtKG/sNVr8FvVoR+lRL8FgW+dp uW/zZHmbEyyYBR2P/XTEdyQ6KpBhR7mDtMmjitzbskKzFoSH5tO0yS2JJkAP2Ian85sY yiyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FTAJTAHdphSA+mdWC5j7m6XkeSqEpCDSNvEt/z6cFZs=; b=rySVCqOnBnVPSdCjm+/OVk0dS0Hzbw7NiXV5cqK4A/AP/zLi4BsKqbOq8eq8T8f+Iw 54guDvvLwsIBmHaCIOe/FOC7C9oQFY9cw/j23rk/Q9WTPv5rwShl9hAKuSkC/UlgwNyK YY7fJAdGbUx6cI+ZiYgES7JiwzgddPEk5BlVbASu9qmDzrX24j7hVyIvqQQDndZ0upNY qL6YwlCluQXNQJVwx2WoXMWvxdlZi0Ap5E8PK9+2izdByJ9Nw+/m4dVy1uo8slkPZf6X mOKGTU7g7C1kvq2Ofi3umwhPfcRzwlzBLbYyuCSXw4T4zzEGEL0hcIdbcq+o53aONDZO M1SA== X-Gm-Message-State: ANhLgQ3J2ARJAv4wk2/JB1Ea+R3Vz4zD++ZuKOONCtx7ABrt6LBhLKiw 60cNBLS5uSgRwIL63Ni+pZJ/mwXMr83gFo+2lkeirhGi X-Google-Smtp-Source: ADFU+vs+fcEO0vrgzkIZFLkKvoWJur6RpROtBHrYkOfEoWS/9TS9j5XftOphgwV9KSjAM+wKDHazPDCU+AKsP1NZMSc= X-Received: by 2002:a92:9889:: with SMTP id a9mr22610496ill.160.1584337287960; Sun, 15 Mar 2020 22:41:27 -0700 (PDT) MIME-Version: 1.0 From: Patrick Oppenlander Date: Mon, 16 Mar 2020 16:41:17 +1100 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: [musl] 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 , 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