Here's a snapshot of the old changes I had: https://reviews.llvm.org/D48381 (hopefully it helps a bit but caveat emptor: this is a quick merge from an old patch, so it's for illustrative purposes only)
On Wed, Jun 20, 2018 at 10:26 AM, Pavel Labath <lab...@google.com> wrote: > From the looks of it, the patch stalled on the part whether we can > consider all-zero UUIDs as valid or not. I've dug around the code a > bit now, and I've found this comment in ObjectFileMachO.cpp. > > // "main bin spec" (main binary specification) data payload is > // formatted: > // uint32_t version [currently 1] > // uint32_t type [0 == unspecified, 1 == > kernel, 2 == user process] > // uint64_t address [ UINT64_MAX if address not > specified ] > // uuid_t uuid [ all zero's if uuid not specified > ] > // uint32_t log2_pagesize [ process page size in log > base 2, e.g. 4k pages are 12. 0 for unspecified ] > > > So it looks like there are situations where we consider all-zero UUIDs > as invalid. > > I guess that means we either have to keep IsValid() definition as-is, > or make ObjectFileMachO check the all-zero case itself. (Some middle > ground may be where we have two SetFromStringRef functions, one which > treats all-zero case specially (sets m_num_uuid_bytes to 0), and one > which doesn't). Then clients can pick which semantics they want. > > > > 1. A variable-length UUID likely incurs an extra heap allocation. > Not really. If you're happy with the current <=20 limit, then you can > just use the existing data structure. Otherwise, you could use a > SmallVector<uint8_t, 20>. > > > 2. Formatting arbitrary length UUIDs as string is a bit inconvenient as > you noted as well. > For the string representation, I would say we should just use the > existing layout of dashes (after 4, 6, 8, 10 and 16 bytes) and just > cut it short when we have less bytes. The implementation of that > should be about a dozen lines of code. > > The fact that these new UUIDs would not be real UUIDs could be solved > by renaming this class to something else, if anyone can think of a > good name for it (I can't). Then the "real" UUIDs will be just a > special case of the new object. > > pl >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev