2018-06-21 23:07:43 +08:00
|
|
|
//===-- UUIDTest.cpp --------------------------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "gtest/gtest.h"
|
|
|
|
|
|
|
|
#include "lldb/Utility/UUID.h"
|
|
|
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
TEST(UUIDTest, RelationalOperators) {
|
|
|
|
UUID empty;
|
Represent invalid UUIDs as UUIDs with length zero
Summary:
During the previous attempt to generalize the UUID class, it was
suggested that we represent invalid UUIDs as length zero (previously, we
used an all-zero UUID for that). This meant that some valid build-ids
could not be represented (it's possible however unlikely that a checksum of
some file would be zero) and complicated adding support for variable
length build-ids (should a 16-byte empty UUID compare equal to a 20-byte
empty UUID?).
This patch resolves these issues by introducing a canonical
representation for an invalid UUID. The slight complication here is that
some clients (MachO) actually use the all-zero notation to mean "no UUID
has been set". To keep this use case working (while making it very
explicit about which construction semantices are wanted), replaced the
UUID constructors and the SetBytes functions with named factory methods.
- "fromData" creates a UUID from the given data, and it treats all bytes
equally.
- "fromOptionalData" first checks the data contents - if all bytes are
zero, it treats this as an invalid/empty UUID.
Reviewers: clayborg, sas, lemo, davide, espindola
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D48479
llvm-svn: 335612
2018-06-26 23:12:20 +08:00
|
|
|
UUID a16 = UUID::fromData("1234567890123456", 16);
|
|
|
|
UUID b16 = UUID::fromData("1234567890123457", 16);
|
|
|
|
UUID a20 = UUID::fromData("12345678901234567890", 20);
|
|
|
|
UUID b20 = UUID::fromData("12345678900987654321", 20);
|
2018-06-21 23:07:43 +08:00
|
|
|
|
|
|
|
EXPECT_EQ(empty, empty);
|
|
|
|
EXPECT_EQ(a16, a16);
|
|
|
|
EXPECT_EQ(a20, a20);
|
|
|
|
|
|
|
|
EXPECT_NE(a16, b16);
|
|
|
|
EXPECT_NE(a20, b20);
|
|
|
|
EXPECT_NE(a16, a20);
|
|
|
|
EXPECT_NE(empty, a16);
|
|
|
|
|
|
|
|
EXPECT_LT(empty, a16);
|
|
|
|
EXPECT_LT(a16, a20);
|
|
|
|
EXPECT_LT(a16, b16);
|
|
|
|
EXPECT_GT(a20, b20);
|
|
|
|
}
|
Represent invalid UUIDs as UUIDs with length zero
Summary:
During the previous attempt to generalize the UUID class, it was
suggested that we represent invalid UUIDs as length zero (previously, we
used an all-zero UUID for that). This meant that some valid build-ids
could not be represented (it's possible however unlikely that a checksum of
some file would be zero) and complicated adding support for variable
length build-ids (should a 16-byte empty UUID compare equal to a 20-byte
empty UUID?).
This patch resolves these issues by introducing a canonical
representation for an invalid UUID. The slight complication here is that
some clients (MachO) actually use the all-zero notation to mean "no UUID
has been set". To keep this use case working (while making it very
explicit about which construction semantices are wanted), replaced the
UUID constructors and the SetBytes functions with named factory methods.
- "fromData" creates a UUID from the given data, and it treats all bytes
equally.
- "fromOptionalData" first checks the data contents - if all bytes are
zero, it treats this as an invalid/empty UUID.
Reviewers: clayborg, sas, lemo, davide, espindola
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D48479
llvm-svn: 335612
2018-06-26 23:12:20 +08:00
|
|
|
|
|
|
|
TEST(UUIDTest, Validity) {
|
|
|
|
UUID empty;
|
|
|
|
std::vector<uint8_t> zeroes(20, 0);
|
|
|
|
UUID a16 = UUID::fromData(zeroes.data(), 16);
|
|
|
|
UUID a20 = UUID::fromData(zeroes.data(), 20);
|
|
|
|
UUID a16_0 = UUID::fromOptionalData(zeroes.data(), 16);
|
|
|
|
UUID a20_0 = UUID::fromOptionalData(zeroes.data(), 20);
|
|
|
|
EXPECT_FALSE(empty);
|
|
|
|
EXPECT_TRUE(a16);
|
|
|
|
EXPECT_TRUE(a20);
|
|
|
|
EXPECT_FALSE(a16_0);
|
|
|
|
EXPECT_FALSE(a20_0);
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(UUIDTest, SetFromStringRef) {
|
|
|
|
UUID u;
|
|
|
|
EXPECT_EQ(32u, u.SetFromStringRef("404142434445464748494a4b4c4d4e4f"));
|
|
|
|
EXPECT_EQ(UUID::fromData("@ABCDEFGHIJKLMNO", 16), u);
|
|
|
|
|
|
|
|
EXPECT_EQ(36u, u.SetFromStringRef("40-41-42-43-4445464748494a4b4c4d4e4f"));
|
|
|
|
EXPECT_EQ(UUID::fromData("@ABCDEFGHIJKLMNO", 16), u);
|
|
|
|
|
|
|
|
EXPECT_EQ(45u, u.SetFromStringRef(
|
|
|
|
"40-41-42-43-4445464748494a4b4c4d4e4f-50515253", 20));
|
|
|
|
EXPECT_EQ(UUID::fromData("@ABCDEFGHIJKLMNOPQRS", 20), u);
|
|
|
|
|
|
|
|
EXPECT_EQ(0u, u.SetFromStringRef("40-41-42-43-4445464748494a4b4c4d4e4f", 20));
|
|
|
|
EXPECT_EQ(0u, u.SetFromStringRef("40xxxxx"));
|
|
|
|
EXPECT_EQ(0u, u.SetFromStringRef(""));
|
|
|
|
EXPECT_EQ(UUID::fromData("@ABCDEFGHIJKLMNOPQRS", 20), u)
|
|
|
|
<< "uuid was changed by failed parse calls";
|
|
|
|
|
|
|
|
EXPECT_EQ(
|
|
|
|
32u, u.SetFromStringRef("404142434445464748494a4b4c4d4e4f-50515253", 16));
|
|
|
|
EXPECT_EQ(UUID::fromData("@ABCDEFGHIJKLMNO", 16), u);
|
|
|
|
}
|
UUID: Add support for arbitrary-sized module IDs
Summary:
The data structure is optimized for the case where the UUID size is <=
20 bytes (standard length emitted by the GNU linkers), but larger sizes
are also possible.
I've modified the string conversion function to support the new sizes as
well. For standard UUIDs it maintains the traditional formatting
(4-2-2-2-6). If a UUID is shorter, we just cut this sequence short, and
for longer UUIDs it will just repeat the last 6-byte block as long as
necessary.
I've also modified ObjectFileELF to take advantage of the new UUIDs and
avoid manually padding the UUID to 16 bytes. While there, I also made
sure the computed UUID does not depend on host endianness.
Reviewers: clayborg, lemo, sas, davide, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D48633
llvm-svn: 335963
2018-06-29 19:20:29 +08:00
|
|
|
|
|
|
|
TEST(UUIDTest, StringConverion) {
|
|
|
|
EXPECT_EQ("40414243", UUID::fromData("@ABC", 4).GetAsString());
|
|
|
|
EXPECT_EQ("40414243-4445-4647", UUID::fromData("@ABCDEFG", 8).GetAsString());
|
|
|
|
EXPECT_EQ("40414243-4445-4647-4849-4A4B",
|
|
|
|
UUID::fromData("@ABCDEFGHIJK", 12).GetAsString());
|
|
|
|
EXPECT_EQ("40414243-4445-4647-4849-4A4B4C4D4E4F",
|
|
|
|
UUID::fromData("@ABCDEFGHIJKLMNO", 16).GetAsString());
|
|
|
|
EXPECT_EQ("40414243-4445-4647-4849-4A4B4C4D4E4F-50515253",
|
|
|
|
UUID::fromData("@ABCDEFGHIJKLMNOPQRS", 20).GetAsString());
|
|
|
|
}
|