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

[Scott Funkenhauser via lldb-dev]

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