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

Wed Jun 20 10:03:37 PDT 2018

I had made a local attempt at making UUID support arbitrary sizes
(part of extracting
the UUIDs from minidumps <https://reviews.llvm.org/D46292>). I ended up
abandoning the UUID changes since there were not strictly in scope and I
also had the same uneasy feeling about how flexible do we really want to be
with UUIDs.

Overall, the change was aesthetically pleasing since the UUID interface can
be cleaned up a bit, but there are a few small downsides I remember:

1. A variable-length UUID likely incurs an extra heap allocation.
2. Formatting arbitrary length UUIDs as string is a bit inconvenient as you
noted as well.

I may have an old patch with these changes, let me dig a bit.

On Wed, Jun 20, 2018 at 9:55 AM, Scott Funkenhauser via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> 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
> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
>
> 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.
>
> On Wed, Jun 20, 2018 at 11:18 AM Pavel Labath <labath at google.com> wrote:
>
>> Thanks for the heads up Scott. I was not aware that lld generates
>> build-ids with different length.
>>
>> Padding would be one option (we already do that to handle the crc
>> pseudo-build-ids), but perhaps a better one would be to teach the
>> class how to handle arbitrary-sized UUIDs (or up to 20 bytes, at
>> least).
>>
>> I don't think there's a fundamental reason reason why only these two
>> lengths are acceptable. The class originally supported 16 bytes only,
>> because that's how mac UUIDs look like. Then, later, when we were
>> bringing up linux, we added 20-byte support because that's what the
>> gnu linkers generated. But, as it seems that this field can be of any
>> size, maybe it's time to teach UUID how to handle the new reality.
>>
>> Have you looked at how hard would it be to implement something like that?
>>
>> pl
>> On Wed, 20 Jun 2018 at 16:05, Scott Funkenhauser via lldb-dev
>> <lldb-dev at lists.llvm.org> wrote:
>> >
>> > Hey guys,
>> >
>> > LLDB uses source/Utility/UUID.cpp to store the build ID. This class
>> only supports 16 or 20 byte IDs.
>> >
>> > 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) https://github.com/llvm-mirror/lldb/blob/
>> 4dc18b8ce3f95c2aa33edc4c821909c329e94be9/source/Plugins/
>> ObjectFile/ELF/ObjectFileELF.cpp#L1279 .
>> >
>> > 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.
>> >
>> > 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).
>> >
>> > 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).
>> >
>> > ex.
>> > Setting a UUID with length of 8, would pad with 8 trailing zeros to
>> have an overall length of 16.
>> > Setting a UUID with length of 17, would pad with 3 trailing zeros to
>> have an overall length of 20.
>> >
>> > Thanks,
>> > Scott
>> >
>> >
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180620/e3550217/attachment.html>