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

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... )
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201022/d4750e75/attachment.html>