Sections containing instructions should be aligned to the architecture's instruction alignment

[pcc]

When assembling the following for AArch64:

        .section        .text.unlikely,"ax",@progbits
.Ltmp4:
        b       .Ltmp4

LLVM's section headers:

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 000078 000029 00      0   0  1
  [ 2] .text             PROGBITS        0000000000000000 000040 000000 00  AX  0   0  4
  [ 3] .text.unlikely    PROGBITS        0000000000000000 000040 000004 00  AX  0   0  1
  [ 4] .symtab           SYMTAB          0000000000000000 000048 000030 18      1   2  8

GNU as section headers:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        0000000000000000 000040 000000 00  AX  0   0  1
  [ 2] .data             PROGBITS        0000000000000000 000040 000000 00  WA  0   0  1
  [ 3] .bss              NOBITS          0000000000000000 000040 000000 00  WA  0   0  1
  [ 4] .text.unlikely    PROGBITS        0000000000000000 000040 000004 00  AX  0   0  4
  [ 5] .symtab           SYMTAB          0000000000000000 000048 000090 18      6   6  8
  [ 6] .strtab           STRTAB          0000000000000000 0000d8 000004 00      0   0  1
  [ 7] .shstrtab         STRTAB          0000000000000000 0000dc 00003b 00      0   0  1

As a result of the LLVM behavior, we can end up misaligning the .text.unlikely section (e.g. if a preceding section contains data of size not a multiple of 4) and causing a crash at runtime.

I think the GNU as behavior makes more sense, and we should adopt that behavior.

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: None (pcc)

When assembling the following for AArch64: ``` .section .text.unlikely,"ax",@progbits .Ltmp4: b .Ltmp4 ``` LLVM's section headers: ``` 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 000078 000029 00 0 0 1 [ 2] .text PROGBITS 0000000000000000 000040 000000 00 AX 0 0 4 [ 3] .text.unlikely PROGBITS 0000000000000000 000040 000004 00 AX 0 0 1 [ 4] .symtab SYMTAB 0000000000000000 000048 000030 18 1 2 8 ``` GNU as section headers: ``` Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 0000000000000000 000040 000000 00 AX 0 0 1 [ 2] .data PROGBITS 0000000000000000 000040 000000 00 WA 0 0 1 [ 3] .bss NOBITS 0000000000000000 000040 000000 00 WA 0 0 1 [ 4] .text.unlikely PROGBITS 0000000000000000 000040 000004 00 AX 0 0 4 [ 5] .symtab SYMTAB 0000000000000000 000048 000090 18 6 6 8 [ 6] .strtab STRTAB 0000000000000000 0000d8 000004 00 0 0 1 [ 7] .shstrtab STRTAB 0000000000000000 0000dc 00003b 00 0 0 1 ``` As a result of the LLVM behavior, we can end up misaligning the `.text.unlikely` section (e.g. if a preceding section contains data of size not a multiple of 4) and causing a crash at runtime.

I think the GNU as behavior makes more sense, and we should adopt that behavior.

[efriedma-quic]

See also #90358 . (Not a duplicate, though.)

[lenary]

I think that #114031 will fix this? Sorry for dropping the ball on finishing that review.

[lenary]

Ah, sorry, that fix is just aarch64, but you want this for all architectures.

[c-rhodes]

this is fixed on trunk: https://godbolt.org/z/668Ed189f

Ah, sorry, that fix is just aarch64, but you want this for all architectures.

I see no mention of other architectures, the reproducer is AArch64 assembly. Going to go ahead and close, I'm missing something w.r.t other architectures please reopen and we can drop the AArch64 label.

[pcc]

This should work the same way on all architectures.

[c-rhodes]

This should work the same way on all architectures.

No worries. Can you be a bit more specific and detail exactly which architectures this is an issue for so the appropriate labels can be added? I can't see this going anywhere otherwise.