[lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD

[Leonard Mosescu via lldb-dev]

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 <labath at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180620/021df3f1/attachment-0001.html>