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 > 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 > 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. Thanks! Cody On Mon, Jan 15, 2024 at 4:30 PM Szabolcs Nagy wrote: > * Cody Wetzel [2024-01-12 17:10:24 -0600]: > > I did actually find that stackoverflow post and tried spinning up a new > > container but the results don't provide any useful information... > > > > / # /tmp/ld-musl-armhf.so.1 /usr/bin/gdb --args ls -l /tmp > > > GNU gdb (GDB) 12.1 > > > Copyright (C) 2022 Free Software Foundation, Inc. > > > License GPLv3+: GNU GPL version 3 or later < > > > http://gnu.org/licenses/gpl.html> > > > This is free software: you are free to change and redistribute it. > > > There is NO WARRANTY, to the extent permitted by law. > > > Type "show copying" and "show warranty" for details. > > > This GDB was configured as "armv7-alpine-linux-musleabihf". > > > Type "show configuration" for configuration details. > > > For bug reporting instructions, please see: > > > . > > > Find the GDB manual and other documentation resources online at: > > > . > > > > > > For help, type "help". > > > Type "apropos word" to search for commands related to "word"... > > > Reading symbols from ls... > > > (No debugging symbols found in ls) > > > (gdb) run > > > Starting program: /bin/ls -l /tmp > > > During startup program terminated with signal SIGSEGV, Segmentation > fault. > > > > > so i looked at alpine armv7 binaries and they seem to be built with > 4k page size. > > since the elf files are not possible to map with 32k pages, it is > expected that they crash on exec in the kernel and thus you get no > backtrace. > > i'm not sure why gdb works, unless it's an old gdb binary that's built > with large pagesize support. > > an easy way to verify is to compare proram headers of old and new > binaries like > > readelf -lW /tmp/ld-musl-armhf.so.1 > -- Cody Wetzel codyawetzel@gmail.com (402)490-9242