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

I didn't know about llvm::SmallVector, but it seems a good match indeed, thanks Greg. On Thu, Jun 21, 2018 at 9:49 AM, Greg Clayton wrote: > > > On Jun 21, 2018, at 9:46 AM, Leonard Mosescu wrote: > > Leonard, I'm not going to use your patch, as it's a bit un-llvm-y >> (uses std::ostream and su

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

> On Jun 21, 2018, at 9:46 AM, Leonard Mosescu wrote: > > Leonard, I'm not going to use your patch, as it's a bit un-llvm-y > (uses std::ostream and such). However, I wanted to check whether 20 > bytes will be enough for your use cases (uuids in minidumps)? > > For minidumps we normally use ei

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

> > Leonard, I'm not going to use your patch, as it's a bit un-llvm-y > (uses std::ostream and such). However, I wanted to check whether 20 > bytes will be enough for your use cases (uuids in minidumps)? > For minidumps we normally use either 16 or 20 byte UUIDs, so I don't see any immediate probl

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

That sounds like a plan. I have started cleaning up the class a bit (removing manual uuid string formatting in various places and such), and then I'll send a patch which implements that. Leonard, I'm not going to use your patch, as it's a bit un-llvm-y (uses std::ostream and such). However, I want

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

I am fine if we go with any number of bytes. We should have the lldb_private::UUID class have an array of bytes that is in the class that is to to 20 bytes. We can increase it later if needed. I would rather not have a dynamically allocated buffer. That being said a few points: - Length can be

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

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 wrote: > From the looks of it, the patch stall

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

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:

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

I had that issue a while back and uploaded a few diffs that fix the problem, but never landed them. I don't remember exactly what needed to change, but you can view them here: https://reviews.llvm.org/D40538 https://reviews.llvm.org/D40537 Let me know if you want to help get them committed to the

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

I had made a local attempt at making UUID support arbitrary sizes (part of extracting the UUIDs from minidumps ). 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 wan

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

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

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

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 le