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

Removing the `llvm::byteswap` causes a testcase where we connect to a simulated big endian target to fail (little endian host -> big endian target). The swap makes the endian of the value match the endian of the target's type system.

> Wait,.. can't the byteswapping be combined with DataExtractor construction below?

Yes you would think that I could flip the endian of the data extractor but that doesn't change anything. Whether the endian there is the input or output endian, for whatever reason, it makes no difference.

It could be that the path that bitfield struct rendering takes is dodging the methods that pay attention to that setting. Could be reading a single byte at a time and for a stream of single bytes there's no endian.

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

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