Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers
wrote:
>
> Dear testers,
>
> 7.0.0-rc1 was just tagged (from the branch at r338847).
>
> It's early in the release process, but I'd like to find out what the
> status is of the branch on our various platforms.
>
> Please run the test script, share the results, and upload binaries.
I've built and tested for FreeBSD 11 (a.k.a 11-STABLE) this time, since
FreeBSD 10 will be going EOL pretty soon now. Uploaded:
SHA256 (clang+llvm-7.0.0-rc1-amd64-unknown-freebsd11.tar.xz) =
ed3191635be26cced8c75d5e57ff7e559f44b927a64c10d22611d8d912cf6df4
I posted the full test results here:
https://gist.github.com/DimitryAndric/64e9a7805a01e6027e2aaabfcda42bed
Summary:
Expected Passes: 50388
Expected Failures : 233
Unsupported Tests : 3687
Unexpected Passes : 1
Unexpected Failures: 2490
The failures are distributed as follows:
2028 libc++
205 AddressSanitizer-i386-freebsd-dynamic
200 AddressSanitizer-x86_64-freebsd-dynamic
20 XRay-Unit
11 MemorySanitizer-Unit
7 lldb-Suite
4 libunwind
3 XRay-x86_64-freebsd
3 lldb
2 ThreadSanitizer-x86_64
2 UBSan-MemorySanitizer-x86_64
2 libFuzzer
1 SanitizerCommon-asan-i386-FreeBSD
1 SanitizerCommon-asan-x86_64-FreeBSD
1 libomp
Almost all libc++ failures are due to FreeBSD missing timespec_get(),
and this became mandatory with https://reviews.llvm.org/rL338419:
In file included from
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/test/libcxx/containers/unord/next_pow2.pass.cpp:26:
In file included from
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/iostream:38:
In file included from
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/ios:216:
In file included from
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/__locale:18:
In file included from
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/mutex:191:
In file included from
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/__mutex_base:15:
In file included from
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/chrono:795:
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/ctime:77:9: error: no
member named 'timespec_get' in the global namespace; did you mean 'timespec'?
using ::timespec_get;
~~^~~~
timespec
/usr/include/sys/_timespec.h:44:8: note: 'timespec' declared here
struct timespec {
^
We're tracking this in FreeBSD here: https://bugs.freebsd.org/230400,
but for existing FreeBSD releases this isn't fixable, so we could really
use some sort of workaround in libc++. :-)
-Dimitry
signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On 6 Aug 2018, at 18:23, Hans Wennborg wrote: > > On Sun, Aug 5, 2018 at 5:49 PM, Dimitry Andric wrote: >> On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers >> wrote: >>> >>> 7.0.0-rc1 was just tagged (from the branch at r338847). ... > >> Hmm, I'm running into a rather nasty snag now on i386-freebsd11, due to our >> lack of atomic 64 bit primitives; Phase2's configure dies with: >> >>-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB >>-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success >>-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB >>-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed >>-- Looking for __atomic_load_8 in atomic >>-- Looking for __atomic_load_8 in atomic - not found ... >> Apparently, with clang 6.0 it didn't generate libcalls to atomic functions, >> but just put in cmpxchg8b's, I guess? And with clang 7.0 this seems to have >> changed. ... > Did you file a bug to track this? (Sorry if you already did, I haven't > read through the list today.) This is a regression caused by https://reviews.llvm.org/rL323281: r323281 | wmi | 2018-01-23 23:27:57 + (Tue, 23 Jan 2018) | 12 lines Adjust MaxAtomicInlineWidth for i386/i486 targets. This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6. Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However, i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg. So in this patch MaxAtomicInlineWidth is reset as follows: For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. Differential Revision: https://reviews.llvm.org/D42154 I'm not sure whether we should report this as an LLVM bug though, since the problem really lies with FreeBSD: we never had proper atomic libcalls in our libc (at least the 64 bit ones for 32-bit x86), nor a separate libatomic. Before r323281, and with all released versions of clang to date, it actually generated incorrect instructions for the default target CPU, if you used the triple i386-unknown-freebsd, e.g.: $ ~/obj/clang-323280/bin/clang -m32 -O2 -S atomic-test.cpp -o - [...] pushl %ebp movl%esp, %ebp pushl %ebx xorl%eax, %eax xorl%edx, %edx xorl%ecx, %ecx xorl%ebx, %ebx lockcmpxchg8b x xorl%eax, %eax popl%ebx popl%ebp retl After r323281, this is corrected: $ ~/obj/clang-323281/bin/clang -m32 -O2 -S atomic-test.cpp -o - [...] pushl %ebp movl%esp, %ebp pushl $0 pushl $x calll __atomic_load_8 addl$8, %esp xorl%eax, %eax popl%ebp retl Targeting i586 or higher makes the cmpxchg8b come back: $ ~/obj/clang-323281/bin/clang -m32 -march=i586 -O2 -S atomic-test.cpp -o - [...] pushl %ebp movl%esp, %ebp pushl %ebx xorl%eax, %eax xorl%edx, %edx xorl%ecx, %ecx xorl%ebx, %ebx lockcmpxchg8b x xorl%eax, %eax popl%ebx popl%ebp retl I think there are other scenarios where you could cause atomic libcalls to appear, though, even if you target higher CPUs. That said, we'll have to at least discuss this in the FreeBSD community, since I think it is high time it is fixed on *that* side. -Dimitry signature.asc Description: Message signed with OpenPGP ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Handling of the ELF files missing build-ids?
Sounds like a plan.
On Tue, 7 Aug 2018 at 01:30, Leonard Mosescu wrote:
>>
>> I am fine with all the above except some reservations about case C. No need
>> to calculate something if it isn't useful. For case C it should be fine to
>> never match as if a file has a UUID to begin with it typically isn't
>> something that gets stripped in a stripped binary. So we should either have
>> it or not. If breakpad does calculate a CRC32, then we need to know to
>> ignore the UUID. The problem is we probably won't be able to tell what the
>> UUID is: real from build ID, or from GNU debug info CRC, or CRC of entire
>> file. So the minidump code will need to do something here. If a minidump has
>> the linux auxv and memory map in them, then we might need to dig through the
>> section information and deduce if a file matches or not based off the size
>> of mapped program headers to further help with the matching.
>>
>> One other idea is to make a set of enumerations for the UUID type:
>>
>> class UUID {
>> enum class Type {
>> BuildID, // A build ID from the compiler or linker
>> GNUDebugInfoCRC, // GNU debug info CRC
>> MD5, // MD5 of entire file
>> MD5NonDebug, // MD5 of the non debug info related bits
>> CRC32, // CRC32 of entire file
>> Other, // Anything else
>> };
>> };
>>
>> The eTypeMD5NonDebug is what apple does: it MD5 checksums only the parts of
>> the file that don't change with debug info or any paths found in debug info
>> or symbols tables. So if you build a binary in /tmp/a or in
>> /private/var/local/foo, the UUID is the same if the binary is essentially
>> the same (code, data, etc).
>>
>> Then we can make intelligent comparisons between UUID types. Might even be
>> possible for a module to have more than 1 UUID then if a binary contains a
>> eTypeBuildID and a eTypeGNUDebugInfoCRC. If a tool stores its UUIDs as a
>> CRC32 or MD5, then those can be calculated on the fly. The GetUUID on
>> lldb_private::Module might become:
>>
>> const lldb_private::UUID ::GetUUID(UUID::Type uuid_type);
>>
>> Thoughts?
>>
>> Greg
>
>
> I like the idea of UUID sub-types! This solves the problem is a more generic
> fashion and it's also extensible. Interestingly enough, for Crashpad we're
> considering something similar (the fabricated UUIDs would have a different
> CvRecord signature)
>
> Case C. is a bit ugly so let me elaborate: this is specific to Breakpad
> minidump + ELF binaries w/o build-id. So we'd still need to have a way to
> force the match of the modules in the minidump with the local files. This
> ought to be an off-by-default, sharp tool which you'd only need to deal with
> Breakpad minidumps, and even then it would only be a fall-back that must be
> explicitly requested.
>
>> 1. .gnu_debuglink separate file pointer
>> .
>> This is where the choice of the crc algorithm comes from.
>
>
> Thanks Pavel. As you noted yourself, this doesn't mean that the UUID has to
> be tied to the checksum (they are exclusive options). In particular, for
> performance reasons I think it's desirable to avoid calculating checksums for
> every ELF module just in case.
>
>> I think we might have something already which could serve this
>> purpose. Eugene added a couple of months ago a mechanism to force-load
>> symbols for a given file regardless of the UUIDs
>> . It requires an explicit "target
>> symbols add" command (which seems reasonable, as lldb has no way to
>> tell if it's doing things right). Would something like that work for
>> you?
>
>
> Nice. We may have to update the C++ API, but something like this would do the
> trick for case C.
>
> To summarize the conversation so far:
>
> 1. We can fix cases A, B independent of C: if real UUIDs are missing, don't
> automatically use full file CRC32 as UUID.
> 2. Pay attention to make sure that we don't break .gnu_debuglink or remote
> debugging (thanks Pavel)
> 3. Multiple types/namespaces for UUIDs would be a great feature!
> 4. Eugene's symbol forcing trick could be extended to handle case C
>
> Did I miss anything?
>
> My current plan is to start with #1, then look into #4 (force symbols match).
>
>
> On Sun, Aug 5, 2018 at 12:11 PM, Pavel Labath wrote:
>>
>> Hello Leonard,
>>
>> while I'm in principle supportive of this idea, I think it's not going
>> to be as easy as you might imagine. There are currently at least two
>> mechanisms which rely on this crc UUID.
>>
>> 1. .gnu_debuglink separate file pointer
>> .
>> This is where the choice of the crc algorithm comes from.
>>
>> In short, this mechanism for debug info location works like this: The
>> stripped file contains a .gnu_debuglink section. The section contains
>> a file path and a crc checksum. After reading this section the
>> debugger is
Re: [lldb-dev] Remove "Either" or not?
I'd vote for removal. This kind of functionality would be better off in llvm's ADT anyway. On Tue, 7 Aug 2018 at 09:18, Tatyana Krasnukha via lldb-dev wrote: > > Hello, > > > > lldb\include\lldb\Utility\Either.h seems dead, at least I couldn’t find any > usages. > > I could enhance it with Bind function for composing monadic functions and add > tests to show usage examples. > > Or just remove it if no one needs it? > > ___ > 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] [7.0.0 Release] Release Candidate 1 source, docs, and binaries available
Hello everyone, Source, docs, and binaries for LLVM-7.0.0-rc1 are now available at http://prereleases.llvm.org/7.0.0/#rc1 I'll add more binaries as they become available. Please try it out and report any problems as bugs marked as blockers of https://llvm.org/PR38406 Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Remove "Either" or not?
Hello, lldb\include\lldb\Utility\Either.h seems dead, at least I couldn't find any usages. I could enhance it with Bind function for composing monadic functions and add tests to show usage examples. Or just remove it if no one needs it? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 38453] lldb: new (unit)test failures in 7.0
https://bugs.llvm.org/show_bug.cgi?id=38453 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||r338949 r339107 CC||h...@chromium.org Status|NEW |RESOLVED --- Comment #3 from Hans Wennborg --- (In reply to Leonard Mosescu from comment #2) > The VMRange failure should be fixed by rL338949 > (https://reviews.llvm.org/D50290) Merged to 7.0 in r339107. -- 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
