libbacktrace: fix unaligned read of the header of the compressed debug section

[ubyte]

The type b_elf_chd requires 8 byte alignment on a 64-bit platform, but a compressed debug section may be stored with less restrictive alignment.
That misalignment read may cause program termination if it was compiled with the UndefinedBehaviorSanitizer enabled.

[ianlancetaylor]

Have you seen a real program with a misaligned SHF_COMPRESSED section? I would expect that tools that generate such sections would use an sh_align field that keeps the compressed section properly aligned. That is what I see when testing with the GNU linker.

[ubyte]

I'm using LD LLD linker from the LLVM project.

$ clang++ --version
clang version 16.0.6
Target: x86_64-unknown-linux-gnu

$ ./ld.lld  --version
LLD 16.0.6 (compatible with GNU linkers)

Have you seen a real program with a misaligned SHF_COMPRESSED section?

Yes, it was a real program for which I recently started using the -gz=zlib option to build.
In fact, almost every program produced by this toolchain began to have unaligned debug sections.
This didn't cause any problems until I tried to run the program with the UB-sanitizer.

This is how the output of the readelf --sections looks like for a simple program

$ readelf --sections  --wide ./a.out
There are 44 section headers, starting at offset 0x2884d0:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        00000000002002a8 0002a8 00001c 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            00000000002002c4 0002c4 000020 00   A  0   0  4
  [ 3] .note.gnu.build-id NOTE            00000000002002e4 0002e4 000024 00   A  0   0  4
  [ 4] .dynsym           DYNSYM          0000000000200308 000308 002130 18   A  8   1  8
  [ 5] .gnu.version      VERSYM          0000000000202438 002438 0002c4 02   A  4   0  2
  [ 6] .gnu.version_r    VERNEED         00000000002026fc 0026fc 000080 00   A  8   3  4
  [ 7] .gnu.hash         GNU_HASH        0000000000202780 002780 000774 00   A  4   0  8
  [ 8] .dynstr           STRTAB          0000000000202ef4 002ef4 001a1e 00   A  0   0  1
  [ 9] .rela.dyn         RELA            0000000000204918 004918 000180 18   A  4   0  8
  [10] .rela.plt         RELA            0000000000204a98 004a98 0006a8 18  AI  4  29  8
  [11] .rodata           PROGBITS        0000000000205140 005140 0127dc 00 AMS  0   0 16
  [12] .gcc_except_table PROGBITS        000000000021791c 01791c 0003a4 00   A  0   0  4
  [13] .eh_frame_hdr     PROGBITS        0000000000217cc0 017cc0 001d44 00   A  0   0  4
  [14] .eh_frame         PROGBITS        0000000000219a08 019a08 009cf0 00   A  0   0  8
  [15] .text             PROGBITS        0000000000223700 023700 08b27a 00  AX  0   0 16
  [16] .init             PROGBITS        00000000002ae97c 0ae97c 00001a 00  AX  0   0  4
  [17] .fini             PROGBITS        00000000002ae998 0ae998 000009 00  AX  0   0  4
  [18] .plt              PROGBITS        00000000002ae9b0 0ae9b0 000480 00  AX  0   0 16
  [19] .tbss             NOBITS          00000000002aee30 0aee30 000008 00 WAT  0   0  8
  [20] .jcr              PROGBITS        00000000002afe30 0aee30 000008 00  WA  0   0  8
  [21] .fini_array       FINI_ARRAY      00000000002afe38 0aee38 000008 00  WA  0   0  8
  [22] .init_array       INIT_ARRAY      00000000002afe40 0aee40 000020 00  WA  0   0  8
  [23] .data.rel.ro      PROGBITS        00000000002afe60 0aee60 0033d8 00  WA  0   0 16
  [24] .preinit_array    PREINIT_ARRAY   00000000002b3238 0b2238 000008 00  WA  0   0  8
  [25] .dynamic          DYNAMIC         00000000002b3240 0b2240 000200 10  WA  8   0  8
  [26] .got              PROGBITS        00000000002b3440 0b2440 0000b0 00  WA  0   0  8
  [27] .tm_clone_table   PROGBITS        00000000002b44f0 0b24f0 000000 00  WA  0   0  8
  [28] .data             PROGBITS        00000000002b44f0 0b24f0 025000 00  WA  0   0 16
  [29] .got.plt          PROGBITS        00000000002d94f0 0d74f0 000250 00  WA  0   0  8
  [30] .bss              NOBITS          00000000002d9740 0d7740 5a6fd0 00  WA  0   0 64
  [31] .gnu_debuglink    PROGBITS        0000000000000000 0d7740 000024 00      0   0  1
  [32] .comment          PROGBITS        0000000000000000 0d7764 000054 01  MS  0   0  1
  [33] .debug_loc        PROGBITS        0000000000000000 0d77b8 03bb49 00   C  0   0  1
  [34] .debug_abbrev     PROGBITS        0000000000000000 113301 007299 00   C  0   0  1
  [35] .debug_info       PROGBITS        0000000000000000 11a59a 07ca20 00   C  0   0  1
  [36] .debug_str        PROGBITS        0000000000000000 196fba 0254f9 01 MSC  0   0  1
  [37] .debug_line       PROGBITS        0000000000000000 1bc4b3 030ac5 00   C  0   0  1
  [38] .debug_ranges     PROGBITS        0000000000000000 1ecf78 00bd1e 00   C  0   0  1
  [39] .debug_aranges    PROGBITS        0000000000000000 1f8c96 000047 00   C  0   0  1
  [40] .gdb_index        PROGBITS        0000000000000000 1f8cdd 06c2f0 00      0   0  1
  [41] .symtab           SYMTAB          0000000000000000 264fd0 00ded8 18     43 1894  8
  [42] .shstrtab         STRTAB          0000000000000000 272ea8 0001c4 00      0   0  1
  [43] .strtab           STRTAB          0000000000000000 27306c 01545e 00      0   0  1
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), l (large), p (processor specific)

[ianlancetaylor]

Thanks. That looks like a bug in lld. It should be setting sh_align to 8, not 1, for a compressed section.

I guess we should work around the bug, though.

[ianlancetaylor]

Thanks, I committed the patch upstream and merged it back into this repo.

[ubyte]

Thank you!

[MaskRay]

On ELF64, it looks like BFD uses 8-byte alignment for compressed .debug_* sections while gold/lld/mold use 1-byte alignment. I do not know how the Solaris linker sets the alignment.

The specification's wording makes me confused whether it really requires 8-byte alignment, even if a non-packed Elf64_Chdr surely requires 8.

The sh_size and sh_addralign fields of the section header for a compressed section reflect the requirements of the compressed section.

There are many .debug_* sections. So avoiding some alignment padding seems a very natural extension, even if the specification doesn't allow it with a very strict interpretation.

[ianlancetaylor]

The compressed section starts with a struct that requires 8-byte alignment on a 64-bit system, so it seems to me that the compressed section should have 8-byte alignment. That's how every other ELF structure works, after all. If this is an exception, then the standard should explicitly call it out as such. What it does say is that sh_align is the alignment requirement for the compressed section, which to me means the alignment required for the data in that section, which to me means requiring 8-byte alignment.