[lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD
Leonard Mosescu via lldb-dev
lldb-dev at lists.llvm.org
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
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
> 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
>> 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?
>> 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/
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev