You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The latest aarch64 ELF loader does not work (nor any cosmopolitan binary):
$ uname -vris
Linux 4.18.0-513.11.1.el8_9.0.1.aarch64 #1 SMP Tue Feb 13 18:47:30 EST 2024 aarch64
$ sha256sum ./ape-aarch64.elf
877ccbd465243065426cb4a3cab4351acad918649f8656556bb604882eead08f ./ape-aarch64.elf
$ ./ape-aarch64.elf
Segmentation fault
$ strace ./ape-aarch64.elf
execve("./ape-aarch64.elf", ["./ape-aarch64.elf"], 0xfffff8fbe7b0 /* 18 vars */) = -1 EINVAL (Invalid argument)
This is on an Ampere CPU.
Looking at the strace output, I think it might be the ancient (and patched by the distros) kernel that does not like Cosmopolitan's ELF file. It could probably be reproduced on a VM.
In addition on gdb, I can't even break on the first instruction:
running an ancient gdb
GNU gdb (GDB) Rocky Linux 8.2-20.el8.0.1
Copyright (C) 2018 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 "aarch64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://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"...
warning: A handler for the OS ABI "FreeBSD" is not built into this configuration
of GDB. Attempting to continue with the default aarch64 settings.
Reading symbols from ./ape-aarch64.elf...(no debugging symbols found)...done.
(gdb) starti
Starting program: /tmp/ape-aarch64.elf
During startup program terminated with signal SIGSEGV, Segmentation fault.
(gdb) info files
Symbols from "/tmp/ape-aarch64.elf".
Local exec file:
`/tmp/ape-aarch64.elf', file type elf64-littleaarch64.
Entry point: 0x1c0
0x0000000000000120 - 0x0000000000000134 is .hash
0x0000000000000138 - 0x0000000000000154 is .gnu.hash
0x0000000000000158 - 0x0000000000000188 is .dynsym
0x0000000000000188 - 0x0000000000000189 is .dynstr
0x0000000000000190 - 0x00000000000001c0 is .rela.dyn
0x00000000000001c0 - 0x00000000000012ec is .text
0x00000000000012ec - 0x000000000000170e is .rodata
0x0000000000005710 - 0x0000000000005820 is .dynamic
0x0000000000005820 - 0x0000000000005838 is .got
0x0000000000005838 - 0x0000000000005850 is .got.plt
(gdb) b 0x1c0
Function "0x1c0" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (0x1c0) pending.
(gdb) r
Starting program: /tmp/ape-aarch64.elf
During startup program terminated with signal SIGSEGV, Segmentation fault.
(gdb) b *0x1c0
Breakpoint 2 at 0x1c0
(gdb) r
Starting program: /tmp/ape-aarch64.elf
During startup program terminated with signal SIGSEGV, Segmentation fault.
The latest aarch64 ELF loader does not work (nor any cosmopolitan binary):
This is on an Ampere CPU.
Looking at the strace output, I think it might be the ancient (and patched by the distros) kernel that does not like Cosmopolitan's ELF file. It could probably be reproduced on a VM.
In addition on gdb, I can't even break on the first instruction:
running an ancient gdb
I think this might be related to this llamafile issue: Mozilla-Ocho/llamafile#345
The text was updated successfully, but these errors were encountered: