<div dir="ltr">I took a quick look, it should be fairly straight forward. The one wrinkle (which is just a design decision) is how to represent the variable length UUID as a human readable string (Ex. 16 byte UUIDs are represented as 

<span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).</span><div><br></div><div>I guess the one thing that is giving me pause, is that according to the spec UUIDs are only supposed to be 16 bytes. UUID.cpp already isn't strictly to spec because 20 byte IDs are already supported, but it seems like supporting arbitrary length IDs is an even further departure from the spec. Maybe this is just semantics and doesn't really matter. I don't have a strong opinion one way or another, you definitely have more context than me, and if you think using arbitrary length IDs makes more sense than padding we can move forward with that solution.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 20, 2018 at 11:18 AM Pavel Labath <<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the heads up Scott. I was not aware that lld generates<br>
build-ids with different length.<br>
<br>
Padding would be one option (we already do that to handle the crc<br>
pseudo-build-ids), but perhaps a better one would be to teach the<br>
class how to handle arbitrary-sized UUIDs (or up to 20 bytes, at<br>
least).<br>
<br>
I don't think there's a fundamental reason reason why only these two<br>
lengths are acceptable. The class originally supported 16 bytes only,<br>
because that's how mac UUIDs look like. Then, later, when we were<br>
bringing up linux, we added 20-byte support because that's what the<br>
gnu linkers generated. But, as it seems that this field can be of any<br>
size, maybe it's time to teach UUID how to handle the new reality.<br>
<br>
Have you looked at how hard would it be to implement something like that?<br>
<br>
pl<br>
On Wed, 20 Jun 2018 at 16:05, Scott Funkenhauser via lldb-dev<br>
<<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hey guys,<br>
><br>
> LLDB uses source/Utility/UUID.cpp to store the build ID. This class only supports 16 or 20 byte IDs.<br>
><br>
> When parsing the .note.gnu.build-id ELF section, any build ID between 4 and 20 bytes will be parsed and saved (which will silently fail if the size isn't 16 or 20 bytes) <a href="https://github.com/llvm-mirror/lldb/blob/4dc18b8ce3f95c2aa33edc4c821909c329e94be9/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L1279" rel="noreferrer" target="_blank">https://github.com/llvm-mirror/lldb/blob/4dc18b8ce3f95c2aa33edc4c821909c329e94be9/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L1279</a> .<br>
><br>
> I discovered this issue because by default LLD will generate a 8 byte build ID, causing LLDB to ignore the .note.gnu.build-id ELF section and compute a crc32 at runtime.<br>
><br>
> Is this a know issue that somebody is already working on? (After a quick search I couldn't find any open bugs with a similar description).<br>
><br>
> Does anybody have any objection to modifying UUID::SetBytes to accept any byte array with a size between 4 - 20 bytes, and pad with zeros to the next largest supported size (either 16 or 20 bytes).<br>
><br>
> ex.<br>
> Setting a UUID with length of 8, would pad with 8 trailing zeros to have an overall length of 16.<br>
> Setting a UUID with length of 17, would pad with 3 trailing zeros to have an overall length of 20.<br>
><br>
> Thanks,<br>
> Scott<br>
><br>
><br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>