From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 926EC283C6 for ; Tue, 30 Jan 2024 11:43:51 +0100 (CET) Received: (qmail 5644 invoked by uid 550); 30 Jan 2024 10:41:26 -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 5606 invoked from network); 30 Jan 2024 10:41:25 -0000 Date: Tue, 30 Jan 2024 11:43:38 +0100 From: Szabolcs Nagy To: Rich Felker Cc: Cody Wetzel , Natanael Copa , musl@lists.openwall.com, Markus Wichmann Message-ID: <20240130104338.GD1254592@port70.net> Mail-Followup-To: Rich Felker , Cody Wetzel , Natanael Copa , musl@lists.openwall.com, Markus Wichmann References: <20240104144811.GO1427497@port70.net> <20240111170323.GP1427497@port70.net> <20240112185713.GQ1427497@port70.net> <20240115223008.GR1427497@port70.net> <20240116182918.GS1427497@port70.net> <20240116204552.GV4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240116204552.GV4163@brightrain.aerifal.cx> Subject: Re: [musl] Segmentation fault musl 1.2.4 * Rich Felker [2024-01-16 15:45:52 -0500]: > On Tue, Jan 16, 2024 at 07:29:18PM +0100, Szabolcs Nagy wrote: > > * Cody Wetzel [2024-01-16 09:21:05 -0600]: > > > Here is the output for the old > > > .... > > > > > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /tmp/ld-musl-armhf.so.1 > > > > > > > > Elf file type is DYN (Shared object file) > > > > Entry point 0x359cd > > > > There are 6 program headers, starting at offset 52 > > > > > > > > Program Headers: > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > > EXIDX 0x07acec 0x0007acec 0x0007acec 0x00008 0x00008 R 0x4 > > > > LOAD 0x000000 0x00000000 0x00000000 0x7acf4 0x7acf4 R E 0x10000 > > > > LOAD 0x07fd6c 0x0008fd6c 0x0008fd6c 0x0054a 0x02258 RW 0x10000 > > > > this load segment is 64k aligned. > > > > > > DYNAMIC 0x07febc 0x0008febc 0x0008febc 0x000c0 0x000c0 RW 0x4 > > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > > > GNU_RELRO 0x07fd6c 0x0008fd6c 0x0008fd6c 0x00294 0x00294 R 0x1 > > > > > > > > Section to Segment mapping: > > > > Segment Sections... > > > > 00 .ARM.exidx > > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > > .rodata .ARM.exidx > > > > 02 .data.rel.ro .dynamic .got .data .bss > > > > 03 .dynamic > > > > 04 > > > > 05 .data.rel.ro .dynamic .got > > > > > > > > > > And the new... > > > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/readelf -lW /lib/ld-musl-armhf.so.1 > > > > > > > > Elf file type is DYN (Shared object file) > > > > Entry point 0x362f1 > > > > There are 6 program headers, starting at offset 52 > > > > > > > > Program Headers: > > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > > > EXIDX 0x07b81c 0x0007b81c 0x0007b81c 0x00008 0x00008 R 0x4 > > > > LOAD 0x000000 0x00000000 0x00000000 0x7b824 0x7b824 R E 0x1000 > > > > LOAD 0x07bd74 0x0007cd74 0x0007cd74 0x0054a 0x0225c RW 0x1000 > > > > this load segment is 4k aligned and offset vs addr is not congruent > > modulo 64k, or 32k, so won't work on systems with such page size. > > > > > > DYNAMIC 0x07bebc 0x0007cebc 0x0007cebc 0x000c0 0x000c0 RW 0x4 > > > > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 > > > > GNU_RELRO 0x07bd74 0x0007cd74 0x0007cd74 0x0028c 0x0028c R 0x1 > > > > > > > > Section to Segment mapping: > > > > Segment Sections... > > > > 00 .ARM.exidx > > > > 01 .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text > > > > .rodata .ARM.exidx > > > > 02 .data.rel.ro .dynamic .got .data .bss > > > > 03 .dynamic > > > > 04 > > > > 05 .data.rel.ro .dynamic .got > > > > > > > > > I hope that helps. > > > > yes, this is a linking issue, not musl libc. > > > > alpine linux links binaries for 4k pagesize only. > > > > arm linkers were updated at some point to create binaries supporting > > up to 64k pagesize. i suspect some ppl ran into issues in practice > > and decided the larger binaries are not worth it, if they dont work > > reliably and forced 4k page size at link time. > > > > you have to raise an issue with alpine linux, if you think 32k > > oage size is useful and reliably supportable. > > Are they using -Wl,-z,separate-code? That incurs a large > binary-size-on-disk penalty when supporting oversized pages, and IIRC > something was done to make the linker default to not supporting > oversized pages when that's used. It might be the reason, if arm > linking is normally expected to use a larger max pagesize. i looked at this now, turns out they just changed the pagesize back to 4k (i missed this change): https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1a26a53a0dee39106ba58fcb15496c5f13074652