MC: "error: A dwo section may not contain relocations" when building with fission + RISCV64

[compnerd]

When building with fission, the DW_AT_high_pc field in .debug_info which is redirected to .debug_info.dwo will contain a label difference. The field is meant to be DW_AT_low_pc relative distance, so the difference is unavoidable. Furthermore, with relaxation, the size of the function may change at link time, and thus needs to be resolved at link time.

It appears that gcc will emit the object file, duplicate it and then "extract the DWO sections" dropping the associated relocations resulting in the file showing no relocations.

// RUN: %clang_cc1 -triple riscv64-unknown-linux-gnu -debug-info-kind=constructor -emit-obj -o %t.o -split-dwarf-file %t.dwo -split-dwarf-output %t.dwo
int f(void) { return 32; }

[MaskRay]

https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation#split-dwarf

-gsplit-dwarf produces a .dwo file which will not be processed by the linker. If .dwo files contain relocations, they will not be resolved. Therefore the practice is that .dwo files do not contain relocations. Since features like address ranges need relocations and cannot be resolved without linking, split DWARF is foundamentally incompatible with linker relaxation.

Let me send a Clang driver patch to disallow -mrelax -gsplit-dwarf for RISC-V...

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

[jrtc27]

So GCC just silently produces broken .dwo files?

[compnerd]

@MaskRay - note that this will occur regardless of the state of -mrelax - the address difference is part of the DWARF specification.

@jrtc27 I can't say so definitely, but from a quick look, it seemed like gcc will just do objcopy --extract-dwo ....o ....dwo which will then just filter any section that has a .dwo suffix into the new object file (which excludes the relocation list). But the DW_AT_high_pc field is still left as a difference of two labels. I don't know if dwp or gdb do something special to restore that to a constant but I find that difficult to believe as the label can be adjusted during the link phase.

[MaskRay]

Yes, GCC -mrelax -gsplit-dwarf output is currently silently broken. It uses a constant in .debug_info.dwo to represent DW_AT_high_pc, which will be wrong when the code ranges decrease.

Correction to myself: -gsplit-dwarf and linker relaxation is not incompatible. It's just unsupported in GCC and LLVM's debug info generator. Using address ranges/location description forms which are based on .debug_addr indexes can describe -mrelax code. The DWARF output will be larger, and likely make split DWARF less useful. Since the implementation is non-trivial and the benefit is unclear, I suggest we have a driver error (https://reviews.llvm.org/D130190) for now.

[llvmbot]

@llvm/issue-subscribers-debuginfo