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
