[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Mon Aug 5 02:05:40 PDT 2024


================
@@ -336,3 +336,52 @@ TEST(MinidumpYAML, ExceptionStream_ExtraParameter) {
                                0xab, 0xad, 0xca, 0xfe}),
             *ExpectedContext);
 }
+
+TEST(MinidumpYAML, MemoryRegion_64bit) {
+  SmallString<0> Storage;
+  auto ExpectedFile = toBinary(Storage, R"(
+--- !minidump
+Streams:
+  - Type:            Memory64List
+    Memory Ranges:
+      - Start of Memory Range: 0x7FFFFFCF0818283
+        Content:               '68656c6c6f'
+      - Start of Memory Range: 0x7FFFFFFF0818283
+        Content:               '776f726c64'
+        )");
+
+  ASSERT_THAT_EXPECTED(ExpectedFile, Succeeded());
+  object::MinidumpFile &File = **ExpectedFile;
+
+  ASSERT_EQ(1u, File.streams().size());
+
+  Expected<ArrayRef<minidump::MemoryDescriptor_64>> ExpectedMemoryList =
+      File.getMemory64List();
+
+  ASSERT_THAT_EXPECTED(ExpectedMemoryList, Succeeded());
+
+  ArrayRef<minidump::MemoryDescriptor_64> MemoryList = *ExpectedMemoryList;
+  ASSERT_EQ(2u, MemoryList.size());
+
+  const minidump::MemoryDescriptor_64 &DescOne = MemoryList[0];
+  ASSERT_EQ(0x7FFFFFCF0818283u, DescOne.StartOfMemoryRange);
+  ASSERT_EQ(5u, DescOne.DataSize);
+
+  const minidump::MemoryDescriptor_64 &DescTwo = MemoryList[1];
+  ASSERT_EQ(0x7FFFFFFF0818283u, DescTwo.StartOfMemoryRange);
+  ASSERT_EQ(5u, DescTwo.DataSize);
+
+  const std::optional<ArrayRef<uint8_t>> ExpectedContent =
+      File.getRawStream(StreamType::Memory64List);
+  ASSERT_TRUE(ExpectedContent);
+  const size_t ExpectedStreamSize = sizeof(Memory64ListHeader) + (sizeof(MemoryDescriptor_64) * 2);
+  ASSERT_EQ(ExpectedStreamSize, ExpectedContent->size());
+
+  Expected<ArrayRef<uint8_t>> DescOneExpectedContentSlice = File.getRawData(DescOne);
+  ASSERT_THAT_EXPECTED(DescOneExpectedContentSlice, Succeeded());
+  ASSERT_EQ("hello", reinterpret_cast<const char *>(DescOneExpectedContentSlice->data()));
----------------
labath wrote:

For `ASSERT_THAT` assertions, the order isn't interchangeable, and its always `ASSERT_THAT(Actual, ExpressionMatchingExpected)`. For `ASSERT_EQ` (and friends), the order is interchangable. LLVM doesn't have strict rules around that or uses them consistently, but I think the `(Actual, Expected)` order is more common, and that's what I'd recommend -- if nothing else, then because it's more consistent with the ASSERT_THAT form.

The reason I'm suggesting ASSERT_THAT is because it's more concise and often produces better error messages. For example, if you test that a vector of two elements, and the vector ends up having three, with a sequence like

```
ASSERT_EQ(vector.size(), 2);
ASSERT_EQ(vector[0], something);
ASSERT_EQ(vector[1], something_else);
```

you will only get an error like `2!=3`, whereas `ASSERT_THAT(vector, ElementsAre(something, something_else))` is much shorter and will print the full contents of actual and expected vectors (if the elements have a reasonable operator<<, but the code works even if they don't)

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


More information about the lldb-commits mailing list