This is the last patch for strict dwarf we found on AIX.
This is for the location expression DW_OP_stack_value, we found this operation is emitted in DWARF 3.
I tried to check this in a low level interface, for example, if we found an attribute is DW_AT_location, then we go through all its location values to find unmatched location expressions. But seems it can not distinguish the operations with other unsigned consts like offsets for some operations.
Now DW_OP_stack_value is added to location attribute as an unsigned value. See:
addUInt(*Loc, dwarf::DW_FORM_data1, dwarf::DW_OP_stack_value); void DwarfUnit::addUInt(DIEValueList &Block, dwarf::Form Form, uint64_t Integer) { addUInt(Block, (dwarf::Attribute)0, Form, Integer); }
There may be some other const unsigned value for the location attribute, like:
void DwarfExpression::addOpPiece(unsigned SizeInBits, unsigned OffsetInBits) { emitOp(dwarf::DW_OP_bit_piece); emitUnsigned(SizeInBits); emitUnsigned(OffsetInBits); } void DIEDwarfExpression::emitUnsigned(uint64_t Value) { CU.addUInt(getActiveDIE(), dwarf::DW_FORM_udata, Value); }
So it is hard to tell in the low-level API if the unsigned integer is from a DW_OP_ or from an unsigned const like above offsets.
I also went through the places where we generate DW_OP_stack_value in llc, it includes 3 places:
1: in DwarfCompileUnit.cpp, it is generated for Wasm target, so I don't change it.
2: in DwarfExpression.cpp, all the places in this file are guarded by DWARF 4. I saw the same strict DWARF check in this file. See https://github.com/llvm/llvm-project/blob/c3f95e9197643b699b891ca416ce7d72cf89f5fc/llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp#L314-L322
3: in DwarfUnit.cpp, this is what I fixed in this patch.
clang-tidy: error: member access into incomplete type 'llvm::TargetMachine' [clang-diagnostic-error]
not useful