================ @@ -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). ---------------- adrian-prantl 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. 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. 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
