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 <nsz@port70.net> wrote:
* Cody Wetzel <codyawetzel@gmail.com> [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:
> > <https://www.gnu.org/software/gdb/bugs/>.
> > Find the GDB manual and other documentation resources online at:
> >     <http://www.gnu.org/software/gdb/documentation/>.
> >
> > 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