Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Hans Wennborg via lldb-dev]

On Tue, Aug 7, 2018 at 9:49 PM, Dimitry Andric  wrote:
> 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.

Thanks for the explanation. Let me know what comes out of the discussion.

Cheers,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Hans Wennborg via lldb-dev]

On Tue, Aug 7, 2018 at 10:38 PM, Louis Dionne  wrote:
>
>
>> On Aug 7, 2018, at 16:17, Dimitry Andric via llvm-dev 
>>  wrote:
>>
>> 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++. :-)
>
> Ugh. The problem here is that libc++ checks whether the underlying C standard 
> library implementation has support for C11 as a whole, not on a 
> function-by-function basis. This means that the easiest workaround is to 
> pretend that FreeBSD does NOT support C11 as a whole, but that is going to be 
> a regression from prior releases, which provided a subset of C11 through 
> libc++.
>
> Generally, I think supporting things on a per-platform basis like this is a 
> bad idea because it becomes a complete maze. Perhaps the current situation 
> justifies a workaround, perhaps only targeted to the LLVM 7 branch. Marshall, 
> what’s your opinion?

Can you please file a release-blocking PR to make this easier to track?

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] The mysterious case of unsupported DW_FORMs

[via lldb-dev]

I posted this suggestion on dwarf-discuss, where I would hope various tool 
maintainers are watching.

The maintainer of dwarfdump says that a new version now "prints the type of 
compression and the compression factor for each compressed section that's being 
reported."  Very small sections (< 100 bytes) tend to get larger, but he says 
he's seeing nearly 10x compression factors on string sections.  Other sections 
are in between these extremes.

Don't know about the GNU tools (readelf, objdump).

Did you file a bug for llvm-dwarfdump?  I haven't noticed one.
--paulr

From: Leonard Mosescu [mailto:mose...@google.com]
Sent: Thursday, August 02, 2018 12:53 PM
To: Robinson, Paul
Cc: LLDB
Subject: Re: [lldb-dev] The mysterious case of unsupported DW_FORMs

Thanks Paul! I have a fix for the LLDB handling of compressed sections in an 
upcoming change (together with improved logging). The email was mostly in case 
some other poor soul hit the same problem (until I get a chance to commit the 
fixes)

(*) none of the tools bothered to make a note that the sections are compressed 
(SHF_COMPRESSED)
That seems like a completely valid feature request.  Again filing a bug would 
be the right tactic.  I'm willing to do this one for you, if you don't have a 
bugzilla account.

I'll open a request for llvm-dwarfdump. If you happen to be in touch with the 
developers of the other tools (readelf, objdump, dwarfdump) feel free to 
forward them the notes.



On Thu, Aug 2, 2018 at 7:21 AM, 
mailto:paul.robin...@sony.com>> wrote:
Why weren't my local LLVM & LLDB builds able to decompress the sections? CMake!

Remembering to delete CMakeCache.txt is usually the part I forget to do.

LLDB tried to decompress, but when failed to do so it carried on returning and 
alter attempting to parse the compressed bytes as is.

A section that is compressed but can't be decompressed should be treated as 
corrupt/unparseable.  That seems like an LLDB bug; do you have an account on 
the project bugzilla?

(*) none of the tools bothered to make a note that the sections are compressed 
(SHF_COMPRESSED)

That seems like a completely valid feature request.  Again filing a bug would 
be the right tactic.  I'm willing to do this one for you, if you don't have a 
bugzilla account.

Thanks,
--paulr


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] The mysterious case of unsupported DW_FORMs

[Leonard Mosescu via lldb-dev]

Great. Thanks for the reminder, here's the llvm-dwarfdump bug




On Wed, Aug 8, 2018 at 7:11 AM,  wrote:

> I posted this suggestion on dwarf-discuss, where I would hope various tool
> maintainers are watching.
>
>
>
> The maintainer of dwarfdump says that a new version now "prints the type
> of compression and the compression factor for each compressed section
> that's being reported."  Very small sections (< 100 bytes) tend to get
> larger, but he says he's seeing nearly 10x compression factors on string
> sections.  Other sections are in between these extremes.
>
>
>
> Don't know about the GNU tools (readelf, objdump).
>
>
>
> Did you file a bug for llvm-dwarfdump?  I haven't noticed one.
>
> --paulr
>
>
>
> *From:* Leonard Mosescu [mailto:mose...@google.com]
> *Sent:* Thursday, August 02, 2018 12:53 PM
> *To:* Robinson, Paul
> *Cc:* LLDB
> *Subject:* Re: [lldb-dev] The mysterious case of unsupported DW_FORMs
>
>
>
> Thanks Paul! I have a fix for the LLDB handling of compressed sections in
> an upcoming change (together with improved logging). The email was mostly
> in case some other poor soul hit the same problem (until I get a chance to
> commit the fixes)
>
>
>
> *(*) none of the tools bothered to make a note that the sections are
> compressed (*
> *SHF_COMPRESSED) *That seems like a completely valid feature request.
> Again filing a bug would be the right tactic.  I'm willing to do this one
> for you, if you don't have a bugzilla account.
>
>
>
> I'll open a request for llvm-dwarfdump. If you happen to be in touch with
> the developers of the other tools (readelf, objdump, dwarfdump) feel free
> to forward them the notes.
>
>
>
>
>
>
>
> On Thu, Aug 2, 2018 at 7:21 AM,  wrote:
>
> Why weren't my local LLVM & LLDB builds able to decompress the sections?
> CMake!
>
>
>
> Remembering to delete CMakeCache.txt is usually the part I forget to do.
>
>
>
> LLDB tried to decompress, but when failed to do so it carried on returning
> and alter attempting to parse the compressed bytes as is.
>
>
>
> A section that is compressed but can't be decompressed should be treated
> as corrupt/unparseable.  That seems like an LLDB bug; do you have an
> account on the project bugzilla?
>
>
>
> *(*) none of the tools bothered to make a note that the sections are
> compressed (**SHF_COMPRESSED)*
>
>
>
> That seems like a completely valid feature request.  Again filing a bug
> would be the right tactic.  I'm willing to do this one for you, if you
> don't have a bugzilla account.
>
>
>
> Thanks,
>
> --paulr
>
>
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev