[clang] [llvm] [DebugInfo] Use DW_op_bit_piece for structured bindings of bitfields (PR #85665)

[John Brawn via llvm-commits]

================
@@ -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:

Ah, I see, I hadn't noticed that (I'd just read the description of DW_OP_bit_piece and hadn't read the general description of composite location descriptions). I had been understanding something like "DW_OP_reg0 RAX, DW_OP_bit_piece 0x3 0x0" to mean "this variable can be found in the 3 bits at offset 0 in RAX", but it actually means something closer to "the bottom 3 bits of this variable can be found in the 3 bits at offset 0 in RAX".

I think this doesn't make much difference though if we restrict DW_OP_bit_piece in the llvm.dbg intrinsics to use it only  for its ability to describe a value stored in part of a register, with the other bits not being described, as I think that's what the behaviour I've currently implemented is. Though maybe it would be better to instead use DW_OP_and and DW_OP_shr to extract the bits from the register. I'll think about this some more.

https://github.com/llvm/llvm-project/pull/85665