When compiling hello world, we can keep the relocations in the executable using linker option --emit-relocs: ... $ gcc hello.c -g -Wl,--emit-relocs ... So we have: ... [35] .debug_info PROGBITS 0000000000000000 000011a0 00000000000005bb 0000000000000000 0 0 1 [36] .rela.debug_info RELA 0000000000000000 00003138 0000000000000c78 0000000000000018 I 44 35 8 ... Using readelf, we find f.i. this string relocation: ... $ readelf -r -w a.out Relocation section '.rela.debug_info' at offset 0x3138 contains 133 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000024 00200000000a R_X86_64_32 0000000000000000 .debug_str + 1a ... for this location: ... <24> DW_AT_comp_dir : (indirect string, offset: 0x1a): /home/abuild/rpmbuild/BUILD/glibc-2.26/csu ... However, if we run dwz, then .debug_info is modified: ... <24> DW_AT_encoding : 5 (signed) ... but .rela.debug_info is not. So, dwz breaks the validity of .rela.debug_info.
I'm not sure how this should be addressed. Refusing to optimize when finding debug .rela sections would fix this, but it would also hurt linux kernel debug info compression, so that's probably not a good idea. I suppose ideally, we'd update the .rela sections (see also PR24344). For now, we could drop the .rela sections, since they're broken. At the very least, we have to emit a warning letting the user know that debug .rela sections are broken.
*** Bug 27029 has been marked as a duplicate of this bug. ***
See also this gcc discussion about --emit-relocs: https://gcc.gnu.org/pipermail/gcc/2020-December/234405.html And this elfutils one: https://sourceware.org/pipermail/elfutils-devel/2020q4/003237.html