[Lldb-commits] [lldb] [lldb] Override default struct layout when building register types (PR #189590)

[David Spickett via lldb-commits]

================
@@ -28,31 +28,18 @@ static void dump_type_value(lldb_private::CompilerType &fields_type, T value,
                             lldb_private::Stream &strm) {
   lldb::ByteOrder target_order = exe_scope->CalculateProcess()->GetByteOrder();
 
-  // For the bitfield types we generate, it is expected that the fields are
-  // in what is usually a big endian order. Most significant field first.
-  // This is also clang's internal ordering and the order we want to print
-  // them. On a big endian host this all matches up, for a little endian
-  // host we have to swap the order of the fields before display.
-  if (target_order == lldb::ByteOrder::eByteOrderLittle) {
-    value = reg_info.flags_type->ReverseFieldOrder(value);
-  }
-
-  // Then we need to match the target's endian on a byte level as well.
+  // The type will be rendered in the target's type system, so it must match
+  // its endian.
   if (lldb_private::endian::InlHostByteOrder() != target_order)
     value = llvm::byteswap(value);
----------------
DavidSpickett wrote:

Yes we store them as host endian but in theory the register value object can hold any endian. In practice it never holds anything but host, but I have later patches that'll account for that even so. I'll do it at the same time as removing the size restriction on the register value handled here.

As to why we swap at all, my understanding is that we are treating the value as if it were target memory, and target memory would be in target endian.

IIRC I needed this swap, but the endian set on the DataExtractor did not matter at least for flags/struct. I'll double check.

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