DW_OP_convert is CU-relative but lldb/dsymutil might have a symmetric bug that treats it as absolute

Project Infrastructure LLVM Dev List Archives
1

DWARFv5, 2.5.1.6:

“[DW_OP_convert] takes one operand, which is an unsigned LEB128 integer that represents the offset of a debugging information entry in the current compilation unit”

We recently ran into a few bugs related to support for DWARFv5’s DW_OP_convert:

  • LLDB seems to treat the operand as absolute, rather than CU relative (this breaks on ELF non-split DWARFv5, and on ELF split DWARFv5 with type units enabled (without type units, the relative/absolute offset is the same, so it works there))
  • GDB, when given Split DWARFv5 input, tries to resolve the CU-relative offset relative to/within the skeleton unit instead of the Split Full Unit.

I’ve disabled LLVM’s DW_OP_convert usage in the above situations in https://github.com/llvm/llvm-project/commit/a66311277af3c254cb73a749e8c4478d50a37bb0 (Well, I didn’t bother with the type unit nuance - so it’s disabled for non-MachO LLDB tuned output in general)

But looking at the implementation of llvm-dsymutil, it looks like it’s treating the DW_OP_convert offset as absolute? This means there may be difficulty in fixing the bug due to the non-standard implementation of DW_OP_convert here.

I’ve got no grand plan - but wanted to bring it up, see if someone could double-check my work. (the dsymutil test case (introduced in https://github.com/llvm/llvm-project/commit/fa37a00044c93d9fa7cf7b2ac6d3c20c71348f10) doesn’t seem to exercise the parsing/rewriting of DW_OP_convert very deeply (the rewritten value is the same as the original - so this doesn’t demonstrate whether the value was rewritten to be absolute or not) - so I can’t tell quickly for sure whether the bug is as I’ve described)

I realize this might be a bit problematic for dsymutil usage because there’s a desire not to duplicate DIEs, and to use cross-CU DIE references where DW_OP_convert doesn’t seem to support such cross-CU DIE references - maybe an extension form would be required, or a type declaration could be inserted into the current CU and have that declaration reference the declaration/definition elsewhere (would be a weird use of DW_AT_specification to have a non-defining declaration refer to a defining declaration that way, though… )