maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/unittests/Utility/UUIDTest.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

96 lines
3.1 KiB
C++
Raw Normal View History

[lldb][NFC] Fix all formatting errors in .cpp file headers Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
//===-- UUIDTest.cpp ------------------------------------------------------===//
Modernize UUID class Instead of a separate GetBytes + GetByteSize methods I introduce a single GetBytes method returning an ArrayRef. This is NFC cleanup now, but it should make handling arbitrarily-sized UUIDs cleaner, should we choose to go that way. I also took the opportunity to add some unit tests for this class. llvm-svn: 335244
2018-06-21 23:07:43 +08:00
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Modernize UUID class Instead of a separate GetBytes + GetByteSize methods I introduce a single GetBytes method returning an ArrayRef. This is NFC cleanup now, but it should make handling arbitrarily-sized UUIDs cleaner, should we choose to go that way. I also took the opportunity to add some unit tests for this class. llvm-svn: 335244
2018-06-21 23:07:43 +08:00
//
//===----------------------------------------------------------------------===//
#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);
Modernize UUID class Instead of a separate GetBytes + GetByteSize methods I introduce a single GetBytes method returning an ArrayRef. This is NFC cleanup now, but it should make handling arbitrarily-sized UUIDs cleaner, should we choose to go that way. I also took the opportunity to add some unit tests for this class. llvm-svn: 335244
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);
Add UUID::SetFromOptionalStringRef, use it in DynamicLoaderDarwin We use UUID::fromOptionalData to read UUID's from the Mach-O files, so UUID's of all 0's are invalid UUID's. We also get uuid's from debugserver, which need to match the file UUID's. So we need an API that treats "000000000" as invalid as well. Added that and use it. Differential Revision: https://reviews.llvm.org/D57195 llvm-svn: 352122
2019-01-25 06:43:44 +08:00
UUID from_str;
from_str.SetFromStringRef("00000000-0000-0000-0000-000000000000");
UUID opt_from_str;
opt_from_str.SetFromOptionalStringRef("00000000-0000-0000-0000-000000000000");
Support build-ids of other sizes than 16 in UUID::SetFromStringRef SBTarget::AddModule currently handles the UUID parameter in a very weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On the other hand, shorter-than-16-bytes UUIDs are completely ignored. In this patch, we change the parsing code to handle UUIDs of arbitrary size. To support arbitrary size UUIDs in SBTarget::AddModule, this patch changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We subtly change the semantics of SetFromStringRef - SetFromStringRef now only succeeds if the entire input is consumed to prevent some prefix-parsing confusion. This is up for discussion, but I believe this is more consistent - we always return false for invalid UUIDs rather than sometimes truncating to a valid prefix. Also, all the call-sites except the API and interpreter seem to expect to consume the entire input. This also adds tests for adding existing modules 4-, 16-, and 20-byte build-ids. Finally, we took the liberty of testing the minidump scenario we care about - removing placeholder module from minidump and replacing it with the real module. Reviewed By: labath, friss Differential Revision: https://reviews.llvm.org/D80755
2020-06-02 04:43:18 +08:00
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
EXPECT_FALSE(empty);
EXPECT_TRUE(a16);
EXPECT_TRUE(a20);
Add UUID::SetFromOptionalStringRef, use it in DynamicLoaderDarwin We use UUID::fromOptionalData to read UUID's from the Mach-O files, so UUID's of all 0's are invalid UUID's. We also get uuid's from debugserver, which need to match the file UUID's. So we need an API that treats "000000000" as invalid as well. Added that and use it. Differential Revision: https://reviews.llvm.org/D57195 llvm-svn: 352122
2019-01-25 06:43:44 +08:00
EXPECT_TRUE(from_str);
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
EXPECT_FALSE(a16_0);
EXPECT_FALSE(a20_0);
Add UUID::SetFromOptionalStringRef, use it in DynamicLoaderDarwin We use UUID::fromOptionalData to read UUID's from the Mach-O files, so UUID's of all 0's are invalid UUID's. We also get uuid's from debugserver, which need to match the file UUID's. So we need an API that treats "000000000" as invalid as well. Added that and use it. Differential Revision: https://reviews.llvm.org/D57195 llvm-svn: 352122
2019-01-25 06:43:44 +08:00
EXPECT_FALSE(opt_from_str);
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, SetFromStringRef) {
UUID u;
Support build-ids of other sizes than 16 in UUID::SetFromStringRef SBTarget::AddModule currently handles the UUID parameter in a very weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On the other hand, shorter-than-16-bytes UUIDs are completely ignored. In this patch, we change the parsing code to handle UUIDs of arbitrary size. To support arbitrary size UUIDs in SBTarget::AddModule, this patch changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We subtly change the semantics of SetFromStringRef - SetFromStringRef now only succeeds if the entire input is consumed to prevent some prefix-parsing confusion. This is up for discussion, but I believe this is more consistent - we always return false for invalid UUIDs rather than sometimes truncating to a valid prefix. Also, all the call-sites except the API and interpreter seem to expect to consume the entire input. This also adds tests for adding existing modules 4-, 16-, and 20-byte build-ids. Finally, we took the liberty of testing the minidump scenario we care about - removing placeholder module from minidump and replacing it with the real module. Reviewed By: labath, friss Differential Revision: https://reviews.llvm.org/D80755
2020-06-02 04:43:18 +08:00
EXPECT_TRUE(u.SetFromStringRef("404142434445464748494a4b4c4d4e4f"));
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
EXPECT_EQ(UUID::fromData("@ABCDEFGHIJKLMNO", 16), u);
Support build-ids of other sizes than 16 in UUID::SetFromStringRef SBTarget::AddModule currently handles the UUID parameter in a very weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On the other hand, shorter-than-16-bytes UUIDs are completely ignored. In this patch, we change the parsing code to handle UUIDs of arbitrary size. To support arbitrary size UUIDs in SBTarget::AddModule, this patch changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We subtly change the semantics of SetFromStringRef - SetFromStringRef now only succeeds if the entire input is consumed to prevent some prefix-parsing confusion. This is up for discussion, but I believe this is more consistent - we always return false for invalid UUIDs rather than sometimes truncating to a valid prefix. Also, all the call-sites except the API and interpreter seem to expect to consume the entire input. This also adds tests for adding existing modules 4-, 16-, and 20-byte build-ids. Finally, we took the liberty of testing the minidump scenario we care about - removing placeholder module from minidump and replacing it with the real module. Reviewed By: labath, friss Differential Revision: https://reviews.llvm.org/D80755
2020-06-02 04:43:18 +08:00
EXPECT_TRUE(u.SetFromStringRef("40-41-42-43-4445464748494a4b4c4d4e4f"));
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
EXPECT_EQ(UUID::fromData("@ABCDEFGHIJKLMNO", 16), u);
Support build-ids of other sizes than 16 in UUID::SetFromStringRef SBTarget::AddModule currently handles the UUID parameter in a very weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On the other hand, shorter-than-16-bytes UUIDs are completely ignored. In this patch, we change the parsing code to handle UUIDs of arbitrary size. To support arbitrary size UUIDs in SBTarget::AddModule, this patch changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We subtly change the semantics of SetFromStringRef - SetFromStringRef now only succeeds if the entire input is consumed to prevent some prefix-parsing confusion. This is up for discussion, but I believe this is more consistent - we always return false for invalid UUIDs rather than sometimes truncating to a valid prefix. Also, all the call-sites except the API and interpreter seem to expect to consume the entire input. This also adds tests for adding existing modules 4-, 16-, and 20-byte build-ids. Finally, we took the liberty of testing the minidump scenario we care about - removing placeholder module from minidump and replacing it with the real module. Reviewed By: labath, friss Differential Revision: https://reviews.llvm.org/D80755
2020-06-02 04:43:18 +08:00
EXPECT_TRUE(
u.SetFromStringRef("40-41-42-43-4445464748494a4b4c4d4e4f-50515253"));
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
EXPECT_EQ(UUID::fromData("@ABCDEFGHIJKLMNOPQRS", 20), u);
Support build-ids of other sizes than 16 in UUID::SetFromStringRef SBTarget::AddModule currently handles the UUID parameter in a very weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On the other hand, shorter-than-16-bytes UUIDs are completely ignored. In this patch, we change the parsing code to handle UUIDs of arbitrary size. To support arbitrary size UUIDs in SBTarget::AddModule, this patch changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We subtly change the semantics of SetFromStringRef - SetFromStringRef now only succeeds if the entire input is consumed to prevent some prefix-parsing confusion. This is up for discussion, but I believe this is more consistent - we always return false for invalid UUIDs rather than sometimes truncating to a valid prefix. Also, all the call-sites except the API and interpreter seem to expect to consume the entire input. This also adds tests for adding existing modules 4-, 16-, and 20-byte build-ids. Finally, we took the liberty of testing the minidump scenario we care about - removing placeholder module from minidump and replacing it with the real module. Reviewed By: labath, friss Differential Revision: https://reviews.llvm.org/D80755
2020-06-02 04:43:18 +08:00
EXPECT_TRUE(u.SetFromStringRef("40-41-42-43-4445464748494a4b4c4d4e4f"));
EXPECT_FALSE(u.SetFromStringRef("40xxxxx"));
EXPECT_FALSE(u.SetFromStringRef(""));
EXPECT_EQ(UUID::fromData("@ABCDEFGHIJKLMNO", 16), u)
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 was changed by failed parse calls";
Support build-ids of other sizes than 16 in UUID::SetFromStringRef SBTarget::AddModule currently handles the UUID parameter in a very weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On the other hand, shorter-than-16-bytes UUIDs are completely ignored. In this patch, we change the parsing code to handle UUIDs of arbitrary size. To support arbitrary size UUIDs in SBTarget::AddModule, this patch changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We subtly change the semantics of SetFromStringRef - SetFromStringRef now only succeeds if the entire input is consumed to prevent some prefix-parsing confusion. This is up for discussion, but I believe this is more consistent - we always return false for invalid UUIDs rather than sometimes truncating to a valid prefix. Also, all the call-sites except the API and interpreter seem to expect to consume the entire input. This also adds tests for adding existing modules 4-, 16-, and 20-byte build-ids. Finally, we took the liberty of testing the minidump scenario we care about - removing placeholder module from minidump and replacing it with the real module. Reviewed By: labath, friss Differential Revision: https://reviews.llvm.org/D80755
2020-06-02 04:43:18 +08:00
EXPECT_TRUE(u.SetFromStringRef("404142434445464748494a4b4c4d4e4f-50515253"));
EXPECT_EQ(UUID::fromData("@ABCDEFGHIJKLMNOPQRS", 20), u);
EXPECT_TRUE(u.SetFromStringRef("40414243"));
EXPECT_EQ(UUID::fromData("@ABCD", 4), u);
EXPECT_FALSE(u.SetFromStringRef("4"));
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: 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());
}