Do debug sections really have alignment requirements?

[benesch]

I just sent up a PR to backtrace-rs (rust-lang/backtrace-rs#344) to add support for compressed debug info sections. One of the big hiccups was the alignment requirement of the CompressionHeader. Does the header really have alignment requirements? My toolchain does not align them at all, AFAICT:

 30 .debug_aranges 00030a70  0000000000000000  0000000000000000  001e8ac3  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 31 .debug_pubnames 000c6d6c  0000000000000000  0000000000000000  001f068e  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 32 .debug_info   00275c12  0000000000000000  0000000000000000  00217825  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 33 .debug_abbrev 00014d8d  0000000000000000  0000000000000000  002f1d16  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 34 .debug_line   00109f88  0000000000000000  0000000000000000  002f4a94  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 35 .debug_frame  00001368  0000000000000000  0000000000000000  00344170  2**3
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 36 .debug_str    0020bbcf  0000000000000000  0000000000000000  003444c2  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 37 .debug_loc    0000b48c  0000000000000000  0000000000000000  003a2514  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 38 .debug_macinfo 00000106  0000000000000000  0000000000000000  003a43b5  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 39 .debug_pubtypes 0010101b  0000000000000000  0000000000000000  003a43da  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 40 .debug_ranges 0009cab0  0000000000000000  0000000000000000  003cb50b  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS

(GCC 9.3.0, stock Ubuntu Eoan.)

I tracked down some related discussion in #230 and so that backtrace PR flips on the new unaligned feature (great timing, so thanks!). But I'm not it's the right solution in this case—maybe there is no alignment requirement for the compression headers? And if so disabling alignment checks everywhere seems heavyweight. I tried looking through the DWARF standard but couldn't find anything one way or another.

[philipc]

My understanding of ELF is that all headers must always be aligned to the natural alignment for the ELF class (32-bit or 64-bit). For compressed sections, the contents of the section are irrelevant (so the DWARF standard won't have anything to say about this). The alignment of the compressed section should be the alignment requirement of the compression header (4 or 8), and the alignment of the uncompressed data should be stored in the ch_addralign field of the header. I guess a common bug will be that tools use the alignment of the uncompressed data for the compressed section too (and vice versa).

If this bug is common for compressed headers, then maybe we should remove the alignment requirement for it. The performance is hardly likely to be relevant if you need to decompress.

[philipc]

http://www.linker-aliens.org/blogs/ali/entry/elf_section_compression/ talks about the design of ELF compression, and an explicit goal was for the compression header to be aligned.

[benesch]

Ah, indeed, thanks for the reference. Looks like there is a bug in binutils that is relevant: https://sourceware.org/bugzilla/show_bug.cgi?id=23919. Weirdly that bug was closed with binutils 2.32, but the misalignment persists for me with 2.34.

[benesch]

Even with a simple C program I cannot manage to find a toolchain that produces aligned compressed debug sections. I've tried gold/lld too now. Huh. Does everyone just get this wrong?!

[benesch]

@philipc since it seems like backtrace-rs wants the unaligned feature for other reasons there is no pressing need for any action here! Happy to have this open since it seems like compressed headers are particularly likely to be misaligned and maybe allowing them to be misaligned should be the default, but also happy for you to close this because it does seem like the default behavior is standards-compliant and correct.

[philipc]

Yep thanks. I'll look into it a bit but the probable outcome is to allow them to be misaligned.

[philipc]

LLVM fixed its output in https://reviews.llvm.org/D60965 and binutils fixed its output in https://sourceware.org/bugzilla/show_bug.cgi?id=23919. That's still relatively new though, so let's handle misaligned for now, and consider changing it back later.