This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Add DW_OP_LLVM_user extension point
ClosedPublic

Authored by scott.linder on Mar 30 2023, 1:53 PM.

Details

Summary

The extension codespace for DWARF expressions (DW_OP_LLVM_{lo,hi}_user)
has shrunk over time, as no extension is ever "retired" in practice. To
facilitate future extensions, this patch reserves one open opcode as an extension
point (0xfe), which is followed by a ULEB128-encoded SubOperation, and
then by the subop's operands.

There is some prior-art, namely DW_OP_AARCH64_operation
(see https://github.com/ARM-software/abi-aa/blob/edd7460d87493fff124b8b5713acf71ffc06ee91/aadwarf64/aadwarf64.rst#45dwarf-expression-operations).

This version makes some different tradeoffs, opting to use a ULEB128 for
the subop encoding for future-proofing.

Diff Detail

Event Timeline

scott.linder created this revision.Mar 30 2023, 1:53 PM
scott.linder requested review of this revision.Mar 30 2023, 1:53 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 30 2023, 1:53 PM

I've also submitted a proposal for a standard version of the operation (thread at https://lists.dwarfstd.org/pipermail/dwarf-discuss/2023-March/002199.html)

Would it make sense to remap the the sub-kinds into a bigger contiguous kind in the LLVM implementation? (I'm not sure, but curious - but probably not?)

llvm/include/llvm/BinaryFormat/Dwarf.def
893

Why is zero reserved? (other than to add a the nop op, so there's something to test before we have any USEROPs implemented?)

llvm/lib/BinaryFormat/Dwarf.cpp
175–208

Hmm, any chance we could condense these into a bigger macro (maybe another .def file) that stamps out all these operations, since we have to stamp these out for each kind of enum?)

scott.linder added inline comments.Apr 5 2023, 1:50 PM
llvm/include/llvm/BinaryFormat/Dwarf.def
893

It was because the encoding for official operations in DWARF completely skips over byte "0", i.e. Table 7.9 in https://dwarfstd.org/doc/DWARF5.pdf begins:

Table 7.9: DWARF operation encodings

OperationNo. of OperandsOperation CodeNotes
Reserved0x01-
Reserved0x02-
DW_OP_addr0x031constant address (size is target specific)

I don't see a particular reason to skip it, but there is also very little lost. I even considered reserving all of the 1-byte encodings, just so there is less of a "early users get a more compact encoding" effect.

I am also fine with just using 0 for the nop operation

llvm/lib/BinaryFormat/Dwarf.cpp
175–208

I'm not sure I understand what you mean; do you mean an improvement over the existing support that could land as NFC before my changes?

dblaikie accepted this revision.Apr 18 2023, 2:43 PM
dblaikie added subscribers: jmorse, aprantl.

Seems OK to me - wouldn't mind a second set of eyes. @jmorse @aprantl

llvm/include/llvm/BinaryFormat/Dwarf.def
893

Ah, fair enough - yeah - maybe using zero would be nice then?

llvm/lib/BinaryFormat/Dwarf.cpp
175–208

Yep - though I'm not sure it's possible (macro can't have #include in it, I guess, so not sure - oh, maybe it'd be another .def file... which takes, via macro definitions, the various name spellings, and then stamps out the lookup/string/etc functions)

This revision is now accepted and ready to land.Apr 18 2023, 2:43 PM

Yeah, conceptually this seems fine to me. We already missed the opportunity to make the OPs ULEBs long ago....

This revision was landed with ongoing or failed builds.Jun 19 2023, 2:47 PM
This revision was automatically updated to reflect the committed changes.