Commit Graph

5 Commits

Author SHA1 Message Date
Jim Ingham f3ecbfc164 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-24 22:43:44 +00:00
Chandler Carruth 2946cd7010 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 08:50:56 +00:00
Pavel Labath 77c397f465 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 11:20:29 +00:00
Pavel Labath 2f93fd1f50 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 15:12:20 +00:00
Pavel Labath 470b286ee5 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 15:07:43 +00:00