================
@@ -132,34 +134,33 @@ TEST_F(SymbolFileDWARFTests,
ParseArangesWithMultipleTerminators) {
// Set the big endian length correctly.
const offset_t binary_data_size = sizeof(binary_data);
binary_data[3] = (uint8_t)binary_data_size - 4;
- DWARFDataExtractor data;
- data.SetData(static_cast<const void *>(binary_data), sizeof binary_data,
- lldb::ByteOrder::eByteOrderBig);
+ llvm::DWARFDataExtractor data(llvm::ArrayRef(binary_data),
+ /*isLittleEndian=*/false, /*AddrSize=*/4);
DWARFDebugArangeSet set;
offset_t off = 0;
llvm::Error error = set.extract(data, &off);
// Multiple terminators are not fatal as they do appear in binaries.
EXPECT_FALSE(bool(error));
// Parser should read all terminators to the end of the length specified.
EXPECT_EQ(off, binary_data_size);
- ASSERT_EQ(set.NumDescriptors(), 2U);
- ASSERT_EQ(set.GetDescriptorRef(0).address, (dw_addr_t)0x1000);
- ASSERT_EQ(set.GetDescriptorRef(0).length, (dw_addr_t)0x100);
- ASSERT_EQ(set.GetDescriptorRef(1).address, (dw_addr_t)0x2000);
- ASSERT_EQ(set.GetDescriptorRef(1).length, (dw_addr_t)0x10);
+ ASSERT_EQ(set.getDescriptorsSize(), 4U);
----------------
labath wrote:
The difference I see is that the name `operator==` does not reek of lldb, and
is also something I can imagine being used in llvm (in tests or maybe even in
production code). That said, I think that going for the higher level API is a
good idea here. With the deletion of lldb class, I was not sure if we should
even have those tests here, as this was something that should theoretically be
tested on the llvm side.
https://github.com/llvm/llvm-project/pull/110058
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
