Statically linked binaries crash with illegal hardware instructions about mold

[rui314]

Thank you for your report! At least one of your crt files is broken. See the following readelf output.

$ readelf -a lib/crti.o
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           AArch64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          280 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         7
  Section header string table index: 1

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .strtab           STRTAB          0000000000000000 0000c8 000049 00      0   0  1
  [ 2] .text             PROGBITS        0000000000000000 000040 000000 00  AX  0   0  4
  [ 3] .note.GNU-stack   PROGBITS        0000000000000000 000040 000000 00      0   0  1
  [ 4] .init             PROGBITS        0000000000000000 000040 000008 00  AX  0   0  1
  [ 5] .fini             PROGBITS        0000000000000000 000048 000008 00  AX  0   0  1
  [ 6] .symtab           SYMTAB          0000000000000000 000050 000078 18      1   3  8
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), p (processor specific)

There are no section groups in this file.

There are no program headers in this file.

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type AArch64 is not currently supported.

Symbol table '.symtab' contains 5 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    4 $x.0
     2: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    5 $x.1
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT    4 _init
     4: 0000000000000000     0 FUNC    GLOBAL DEFAULT    5 _fini

No version information found in this file.

.init and .fini are marked as executable sections, but their alignment requirements are set to just 1. Since all instructions need to be aligned to 4 byte boundaries on ARM64, the processor report it as an illegal instruction. mold just does what that is told to do, so it's not a mold's bug. Maybe with other linkers .inti and .fini happen to be aligned to 4 byte boundaries, but depending on that coincidence is wrong.

Please report it to your distro vendor so that they can fix their shipped binary files.

For tracking purposes, please share the bug report link as a reply to this issue. Thanks!

[mojyack]

Thanks for taking the time.
This bug seems to be a musl issue.
I was able to fix this by applying this patch to musl:

diff --git a/crt/aarch64/crti.s b/crt/aarch64/crti.s
index 775df0ac..3776fa64 100644
--- a/crt/aarch64/crti.s
+++ b/crt/aarch64/crti.s
@@ -1,6 +1,7 @@
 .section .init
 .global _init
 .type _init,%function
+.align 2
 _init:
 	stp x29,x30,[sp,-16]!
 	mov x29,sp
@@ -8,6 +9,7 @@ _init:
 .section .fini
 .global _fini
 .type _fini,%function
+.align 2
 _fini:
 	stp x29,x30,[sp,-16]!
 	mov x29,sp

[mojyack]

I would like to send this patch to the musl team, but I am not familiar with the mailing list.
So I am thinking of sending it to the Gentoo repository.
Any ideas?

[rui314]

If you report the issue to Gentoo, I'm sure they'll forward it to upstream if it's an upstream bug.

[mojyack]

I see, I'll do that.

[mojyack]

https://bugs.gentoo.org/931782
bug report posted

[rui314]

I'll close this issue as it's not mold's bug.