<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I am fine if we go with any number of bytes. We should have the lldb_private::UUID class have an array of bytes that is in the class that is to to 20 bytes. We can increase it later if needed. I would rather not have a dynamically allocated buffer.<div class=""><br class=""></div><div class="">That being said a few points:</div><div class="">- Length can be set to zero to indicate invalid UUID. Better that than filling in all zeroes and having to check for that IMHO. I know there were some problems with the last patch around this.</div><div class="">- Don't set length to a valid value and have UUID contain zeros unless that is a true UUID that was calculated. LLDB does a lot of things by matching UUID values so we can't have multiple modules claiming to have a UUID that is filled with zeroes, otherwise many matches will occur that we don't want</div><div class="">- 32 bit GNU debug info CRCs from ELF notes could be filled in as 4 byte UUIDs</div><div class="">- Comparing two UUIDs can start with the length field first the if they match proceed to compare the bytes (which is hopefully what is already happening)</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 20, 2018, at 11:01 AM, Leonard Mosescu via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Here's a snapshot of the old changes I had: <a href="https://reviews.llvm.org/D48381" class="">https://reviews.llvm.org/D48381</a></div><div class="">(hopefully it helps a bit but caveat emptor: this is a quick merge from an old patch, so it's for illustrative purposes only)</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jun 20, 2018 at 10:26 AM, Pavel Labath <span dir="ltr" class=""><<a href="mailto:labath@google.com" target="_blank" class="">labath@google.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From the looks of it, the patch stalled on the part whether we can<br class="">
consider all-zero UUIDs as valid or not. I've dug around the code a<br class="">
bit now, and I've found this comment in ObjectFileMachO.cpp.<br class="">
<br class="">
// "main bin spec" (main binary specification) data payload is<br class="">
// formatted:<br class="">
// uint32_t version [currently 1]<br class="">
// uint32_t type [0 == unspecified, 1 ==<br class="">
kernel, 2 == user process]<br class="">
// uint64_t address [ UINT64_MAX if address not specified ]<br class="">
// uuid_t uuid [ all zero's if uuid not specified ]<br class="">
// uint32_t log2_pagesize [ process page size in log<br class="">
base 2, e.g. 4k pages are 12. 0 for unspecified ]<br class="">
<br class="">
<br class="">
So it looks like there are situations where we consider all-zero UUIDs<br class="">
as invalid.<br class="">
<br class="">
I guess that means we either have to keep IsValid() definition as-is,<br class="">
or make ObjectFileMachO check the all-zero case itself. (Some middle<br class="">
ground may be where we have two SetFromStringRef functions, one which<br class="">
treats all-zero case specially (sets m_num_uuid_bytes to 0), and one<br class="">
which doesn't). Then clients can pick which semantics they want.<br class="">
<span class=""><br class="">
<br class="">
> 1. A variable-length UUID likely incurs an extra heap allocation.<br class="">
</span>Not really. If you're happy with the current <=20 limit, then you can<br class="">
just use the existing data structure. Otherwise, you could use a<br class="">
SmallVector<uint8_t, 20>.<br class="">
<span class=""><br class="">
> 2. Formatting arbitrary length UUIDs as string is a bit inconvenient as you noted as well.<br class="">
</span>For the string representation, I would say we should just use the<br class="">
existing layout of dashes (after 4, 6, 8, 10 and 16 bytes) and just<br class="">
cut it short when we have less bytes. The implementation of that<br class="">
should be about a dozen lines of code.<br class="">
<br class="">
The fact that these new UUIDs would not be real UUIDs could be solved<br class="">
by renaming this class to something else, if anyone can think of a<br class="">
good name for it (I can't). Then the "real" UUIDs will be just a<br class="">
special case of the new object.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
pl<br class="">
</font></span></blockquote></div><br class=""></div>
_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br class=""></div></blockquote></div><br class=""></div></body></html>