[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:

> I'll check what happens to vectors because they can have multi-byte element types.

Changing the way we handle the register value swaps the order of the bytes, so I can confirm that the register value needs to be swapped into target endian one way or another.

The data extractor's order seems to make no difference. This may be because I'm using a very limited set of C types for these registers, where somehow the order doesn't matter. Methods within data extractor do check and use the order, so if it's a bug it's well hidden. Maybe something is getting at the raw data buffer, I don't know.

So really I'm setting the data extractor order to target endian just so it doesn't look suspicious to anyone reading it. Even though it kinda is, but not in a way that concerns this code.

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