[lldb-dev] [Bug 37873] New: Building LLDB with mingw-w64 broken

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=37873

Bug ID: 37873
   Summary: Building LLDB with mingw-w64 broken
   Product: lldb
   Version: 6.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: alexey.paw...@gmail.com
CC: llvm-b...@lists.llvm.org

Building LLDB with mingw-w64 broked by
https://github.com/llvm-mirror/lldb/commit/b984165b795e1817e3e41988a8894f755b575db4#diff-4ca0157b507067ecb5603607ef82da11

Fix is:

--- lldb/include/lldb/lldb-defines.h2018-06-14 10:47:59.093121500 +0300
+++ lldb/include/lldb/lldb-defines.h2018-06-14 10:48:12.399156100 +0300
@@ -12,15 +12,15 @@

 #include "lldb/lldb-types.h"

-#if defined(_MSC_VER)
+#if defined(_WIN32)
 #if defined(EXPORT_LIBLLDB)
 #define LLDB_API __declspec(dllexport)
 #elif defined(IMPORT_LIBLLDB)
 #define LLDB_API __declspec(dllimport)
 #else
 #define LLDB_API
 #endif
-#else // defined (_MSC_VER)
+#else // defined (_WIN32)
 #define LLDB_API
 #endif

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 37873] Building LLDB with mingw-w64 broken

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=37873

lab...@google.com changed:

   What|Removed |Added

 CC||lab...@google.com
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from lab...@google.com ---
I have applied the fix as r335112, thanks.

As you must have noticed, nobody builds/tests lldb with this toolchain, so be
on the lookout for other potential issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 37840] incorrect results of expression evaluation

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=37840

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Assignee|lldb-dev@lists.llvm.org |lab...@google.com
 CC||lab...@google.com
 Resolution|--- |FIXED

--- Comment #5 from lab...@google.com ---
This should be fixed by r335114.

Jim, Davide: sorry for jumping the gun. I noticed you were investigating this
too only when I came here to close the bug. Let me know if you're happy with
the fix or you think there is something more to be done here.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Scott Funkenhauser via lldb-dev]

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@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Pavel Labath via lldb-dev]

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
 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@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [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
----).

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  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
>  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@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Leonard Mosescu via lldb-dev]

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 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@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  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
>>  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@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Stephane Sezer via lldb-dev]

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 tree.

On Wed, Jun 20, 2018 at 8:05 AM Scott Funkenhauser via lldb-dev <
lldb-dev@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@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-- 
-- 
Stephane Sezer
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Pavel Labath via lldb-dev]

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.

> 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [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  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.
>
> > 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
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev