================ @@ -6178,10 +6178,16 @@ The current supported opcode vocabulary is limited: the last entry from the second last entry and appends the result to the expression stack. - ``DW_OP_plus_uconst, 93`` adds ``93`` to the working expression. -- ``DW_OP_LLVM_fragment, 16, 8`` specifies the offset and size (``16`` and ``8`` - here, respectively) of the variable fragment from the working expression. Note - that contrary to DW_OP_bit_piece, the offset is describing the location - within the described source variable. +- ``DW_OP_LLVM_fragment, 16, 8`` specifies that the top of the expression stack + is a fragment of the source language variable with the given offset and size + (``16`` and ``8`` here, respectively). Note that the offset and size are the + opposite way around to ``DW_OP_bit_piece``, and the offset is within the + source language variable. +- ``DW_OP_bit_piece, 8, 16`` specifies that the source language variable can be + found in the sequence of bits at the given size and offset (``8`` and ``16`` + here, respectively) within the top of the expression stack. Note that the + offset and size are the opposite way around to ``DW_OP_LLVM_fragment``, and the + offset is within the LLVM variable (if that's at the top of the stack). ---------------- john-brawn-arm wrote:
> So that effectively implements option (1) that I outlined above. I think this > is a reasonable choice and consistent with how DWARF uses them. So if we do > this (and I think that's fine) we need make sure that the bit pieces are > correctly reported by DIExpression::getFragmentInfo() or else they will get > incorrectly treated by every pass that needs to determine overlapping > fragments. I'm handling this in the next part, which is SROA support (https://github.com/john-brawn-arm/llvm-project/tree/sroa_bit_piece), though it turns out in most of the places that getFragmentInfo is used it actually is specific to DW_OP_LLVM_fragment and does the wrong thing for DW_OP_bit_piece, so I think adding a separate getBitPieceInfo is simpler. > At the very least there should be tests that have LLVM IR that mix & matches > DW_OP_bit_piece and DW_OP_LLVM_fragment for the same variable and confirm > that this gets lowered into valid DWARF. Alternatively, if you want to make > quick progress, you can also say that we don't support this for now and > actively reject mixing the two within the same variable in the Verifyer. The > you'd need to make sure that passes like SROA that introduce new fragments > deal with this gracefully by creating undef locations. Currently if the same variable has a DW_OP_LLVM_fragment and anything else this causes assertion failures in DebugLocEntry::finalize in llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp. https://github.com/llvm/llvm-project/pull/85665 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
