<div dir="ltr">DWARFv5, <a href="http://2.5.1.6">2.5.1.6</a>:<br><br>"[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"<br><br>We recently ran into a few bugs related to support for DWARFv5's DW_OP_convert:<br><br>* 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))<br>* 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.<br><br>I've disabled LLVM's DW_OP_convert usage in the above situations in <font color="#1a73e8" face="WorkAroundWebKitAndMozilla, monospace"><span class="gmail-ng-star-inserted" style="border-style:initial;border-color:initial;outline-color:initial;outline-style:initial;letter-spacing:0.185714px"></span></font><span style="margin:0px;border:0px;font-weight:inherit;font-style:inherit;font-size:13px;vertical-align:baseline;text-decoration-line:none;outline:0px"><a class="gmail-keep-focus-ring" rel="noopener noreferrer" target="_self" href="https://github.com/llvm/llvm-project/commit/a66311277af3c254cb73a749e8c4478d50a37bb0" style="color:rgb(26,115,232);font-family:inherit;margin:0px;border:0px;font-weight:inherit;font-style:inherit;font-size:13px;vertical-align:baseline;text-decoration-line:none">https://github.com/llvm/llvm-project/commit/a66311277af3c254cb73a749e8c4478d50a37bb0</a><font color="#202124" face="WorkAroundWebKitAndMozilla, monospace"><span style="letter-spacing:0.185714px"> </span></font></span>(Well, I didn't bother with the type unit nuance - so it's disabled for non-MachO LLDB tuned output in general)<br><br>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.<br><br>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 <a href="https://github.com/llvm/llvm-project/commit/fa37a00044c93d9fa7cf7b2ac6d3c20c71348f10">https://github.com/llvm/llvm-project/commit/fa37a00044c93d9fa7cf7b2ac6d3c20c71348f10</a>) 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)<br><br>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... )<br><br></div>