Re: [lldb-dev] [llvm-dev] [11.0.0 Release] The release branch is here; trunk is now 12.0.0

2020-07-15 Thread Louis Dionne via lldb-dev 
Thanks for tagging, Hans. Can I go ahead with the CMake version bump advertised 
in http://lists.llvm.org/pipermail/llvm-dev/2020-June/142893.html?

This may cause some instability on a few builders that have not upgraded to a 
recent CMake yet, but I'll iterate as explained in the linked thread. Let me 
know if it's OK to go ahead now or if you'd prefer that I wait for a few days.

Cheers,
Louis

> On Jul 15, 2020, at 08:09, Hans Wennborg via llvm-dev 
>  wrote:
> 
> Hello everyone,
> 
> The release branch for LLVM 11 was created from the trunk at
> 2e10b7a39b930ef8d9c4362509d8835b221fbc0a, and the trunk version was
> bumped to 12.0.0.
> 
> Release blockers are tracked by https://llvm.org/PR46725 Please mark
> any bugs, old or new, that need to be fixed before the release as
> blocking that bug.
> 
> Please keep me in the loop via email on any bugs, commits, or other
> issues that might be relevant for the release. In particular, if
> you're currently investigating issues with trunk and working on fixes,
> please help me make sure that those fixes end up on the branch also.
> 
> To get a change committed to the branch, please commit it to trunk as
> per usual, and then request it to be merged -- ideally by filing a
> blocker of https://llvm.org/PR46725, or by cc'ing me on the commit
> email.
> 
> (Please don't report issues or request merges over
> IRC/Discord/Discourse; there's a large risk that I'll miss it. Please
> use email.)
> 
> The first release candidate will be tagged soon (hopefully in a day or
> two if the branch looks stable), and testing of that can begin. The
> full release schedule can be found under "Upcoming Releases" to the
> right at https://llvm.org
> 
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [lldb-dev] [llvm-dev] [11.0.0 Release] The release branch is here; trunk is now 12.0.0

2020-07-16 Thread Louis Dionne via lldb-dev 
Thanks! I've just pushed the commit and will iterate on it until everyone is 
upgraded.

Happy to finally get this started!
Louis

> On Jul 16, 2020, at 10:34, Hans Wennborg  wrote:
> 
> Sounds good to me.
> 
> On Wed, Jul 15, 2020 at 8:25 PM Louis Dionne  wrote:
>> 
>> Thanks for tagging, Hans. Can I go ahead with the CMake version bump 
>> advertised in http://lists.llvm.org/pipermail/llvm-dev/2020-June/142893.html?
>> 
>> This may cause some instability on a few builders that have not upgraded to 
>> a recent CMake yet, but I'll iterate as explained in the linked thread. Let 
>> me know if it's OK to go ahead now or if you'd prefer that I wait for a few 
>> days.
>> 
>> Cheers,
>> Louis
>> 
>>> On Jul 15, 2020, at 08:09, Hans Wennborg via llvm-dev 
>>>  wrote:
>>> 
>>> Hello everyone,
>>> 
>>> The release branch for LLVM 11 was created from the trunk at
>>> 2e10b7a39b930ef8d9c4362509d8835b221fbc0a, and the trunk version was
>>> bumped to 12.0.0.
>>> 
>>> Release blockers are tracked by https://llvm.org/PR46725 Please mark
>>> any bugs, old or new, that need to be fixed before the release as
>>> blocking that bug.
>>> 
>>> Please keep me in the loop via email on any bugs, commits, or other
>>> issues that might be relevant for the release. In particular, if
>>> you're currently investigating issues with trunk and working on fixes,
>>> please help me make sure that those fixes end up on the branch also.
>>> 
>>> To get a change committed to the branch, please commit it to trunk as
>>> per usual, and then request it to be merged -- ideally by filing a
>>> blocker of https://llvm.org/PR46725, or by cc'ing me on the commit
>>> email.
>>> 
>>> (Please don't report issues or request merges over
>>> IRC/Discord/Discourse; there's a large risk that I'll miss it. Please
>>> use email.)
>>> 
>>> The first release candidate will be tagged soon (hopefully in a day or
>>> two if the branch looks stable), and testing of that can begin. The
>>> full release schedule can be found under "Upcoming Releases" to the
>>> right at https://llvm.org
>>> 
>>> Thanks,
>>> Hans
>>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 

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

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

2021-02-13 Thread Louis Dionne via lldb-dev 


> On Feb 13, 2021, at 12:04, Dimitry Andric  wrote:
> 
> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev 
>  wrote:
>> 
>> I've tagged the 12.0.0-rc1 release.  Testers can begin testing and upload 
>> binaries.
> 
> During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest 
> failure, which turned out to be caused by recent libc++ changes:
> 
>  FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
>  cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && 
> /usr/local/bin/cmake -E env 
> CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib 
> /usr/local/bin/python3.7 -m unittest discover
>  
> 
> The '' signifies 8 errors, which become more clear if "unittest 
> discover" is run with the -f (fail immediately) and -v (verbose) options:
> 
>  $ cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && 
> /usr/local/bin/cmake -E env 
> CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib 
> /usr/local/bin/python3.7 -m unittest discover -f -v
>  test_access_specifiers 
> (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
>  Ensure that C++ access specifiers are available on cursors ... ERROR
> 
>  ==
>  ERROR: test_access_specifiers 
> (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
>  Ensure that C++ access specifiers are available on cursors
>  --
>  Traceback (most recent call last):
>File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 4173, in get_cindex_library
>  library = cdll.LoadLibrary(self.get_filename())
>File "/usr/local/lib/python3.7/ctypes/__init__.py", line 442, in 
> LoadLibrary
>  return self._dlltype(name)
>File "/usr/local/lib/python3.7/ctypes/__init__.py", line 364, in __init__
>  self._handle = _dlopen(self._name, mode)
>  OSError: 
> /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: 
> Undefined symbol "_ZnamSt11align_val_t"
> 
>  During handling of the above exception, another exception occurred:
> 
>  Traceback (most recent call last):
>File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/test_access_specifiers.py",
>  line 29, in test_access_specifiers
>  """, lang = 'cpp')
>File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/util.py",
>  line 41, in get_tu
>  source)])
>File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 2812, in from_source
>  index = Index.create()
>File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 2699, in create
>  return Index(conf.lib.clang_createIndex(excludeDecls, 0))
>File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 212, in __get__
>  value = self.wrapped(instance)
>File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 4147, in lib
>  lib = self.get_cindex_library()
>File 
> "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", 
> line 4178, in get_cindex_library
>  raise LibclangError(msg)
>  clang.cindex.LibclangError: 
> /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: 
> Undefined symbol "_ZnamSt11align_val_t". To provide a path to libclang use 
> Config.set_library_path() or Config.set_library_file().
> 
>  --
>  Ran 1 test in 0.027s
> 
>  FAILED (errors=1)
> 
> It turns out that libc++.so.1 now depends on the symbol 
> '_ZnamSt11align_val_t', which is 'operator new [](unsigned long, 
> std::align_val_t)'. Embarassingly, libc++.so.1 has always depended on this 
> C++17 specific variant of operator new. But FreeBSD's C++ ABI library, 
> libcxxrt, has never supported this variant!
> 
> Previously, this never was a problem, because libc++ provided its own weak 
> definitions of these operators. But recently the define 
> _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS was toggled to on by default, which 
> disables those definitions. This happened in 
> 9b40ee8eb0c194f4b2787801ac6f9ef8fc1b8f46 ("[libc++] Define new/delete in 
> libc++abi only by default") by Louis Dionne.
> 
> While this is reasonable for the libc++abi situation, where it might lead to 
> circular dependencies, I would like to turn the definitions on again in case 
> libcxxrt is used for the C++ ABI, such as on FreeBSD.
> 
> If you think this is a reasonable approach, I will create a review for it. 
> Otherwise, I will have to patch the test-release.sh script to pass 
> -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on 
> FreeBSD.

The correct approach would be to have a CMake cache file under 
libcxx/cmake/cache/FreeBSD.cmake that sets the right conf

Re: [lldb-dev] Some API test failures are really opaque/could be improved

2021-10-25 Thread Louis Dionne via lldb-dev 
I believe the issue is probably not related so much to LLVM_ENABLE_PROJECTS vs 
LLVM_ENABLE_RUNTIMES, but rather to the fact that LLVM_ENABLE_RUNTIMES uses 
per-target runtime directories now (hasn't always been the case), which 
basically means that libc++ ends up in `/lib//libc++.so` 
instead of `/lib/libc++.so`.

I think you either want to specify the per-target library dir when running 
against libc++, or you want to disable that and use 
`LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF` when configuring the runtimes. In all 
cases, you want to be using `LLVM_ENABLE_RUNTIMES` and not 
`LLVM_ENABLE_PROJECTS`, since the latter is deprecated now.

Cheers,
Louis

> On Oct 25, 2021, at 13:57, David Blaikie  wrote:
> 
> +Louis Dionne  - perhaps the libcxx and lldb folks 
> would be interesting in finding a suitable way to address this issue, since 
> currently either option (using libcxx in ENABLE_PROJECTS or using it in 
> ENABLE_RUNTIMES) is incomplete - if I use ENABLE_RUNTIMES I get the libcxx 
> testing run against the just-built clang and generally this is the 
> "supported" configuration, but then some lldb tests fail because they can't 
> find libcxx.so.1 (on Linux) - and using ENABLE_PROJECTS means not using the 
> just-built clang for libcxx tests (so missing the libcxx breakages caused by 
> my array name change) but do use the just-built libcxx in lldb tests and find 
> failures there... 
> 
> On Wed, Oct 20, 2021 at 1:57 PM David Blaikie  > wrote:
> On Tue, Oct 19, 2021 at 4:55 PM David Blaikie  > wrote:
> On Tue, Oct 19, 2021 at 9:08 AM Raphael Isemann  > wrote:
> Actually the RPATH theory is wrong, but the LLVM_ENABLE_PROJECT
> workaround *should* still work.
> 
> I'll give that a go (it's running at the moment) though I guess this is 
> inconsistent with the direction libcxx is moving in for building, re: 
> https://groups.google.com/g/llvm-dev/c/tpuLxk_ipLw 
> 
> 
> Yep, it does work with LLVM_ENABLE_PROJECT rather than LLVM_ENABLE_RUNTIME.
> 
> Specifically the test binary is linked with an rpath to the just-built lib 
> directory that ensures the just-built libc++.so is found:
> 
> /usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang main.o -g -O0 
> -fno-builtin -m64  
> -I/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/make/../../../../../include
>  
> -I/usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/list
>  
> -I/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/make
>  -include 
> /usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/make/test_common.h
>  -fno-limit-debug-info  -gsplit-dwarf-stdlib=libc++ 
> -Wl,-rpath,/usr/local/google/home/blaikie/dev/llvm/build/release/./lib 
> --driver-mode=g++ -o "a.out"
>  
> Oh, actually it passes the same rpath when using LLVM_ENABLE_RUNTIME, but the 
> libc++.so.1 is in a different place: 
> ./lib/x86_64-unknown-linux-gnu/libc++.so.1
> 
> Looks like this rpath setting happens here: (changing this to a junk argument 
> causes the test to fail to build as expected)
> https://github.com/llvm/llvm-project/blob/618583565687f5a494066fc902a977f6057fc93e/lldb/packages/Python/lldbsuite/test/make/Makefile.rules#L400
>  
> 
> 
> And it gets the LLVM_LIBS_DIR from here: 
> https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/lldb/test/API/lit.cfg.py#L163
>  
> 
> 
> So maybe we need to pass down the default target triple too, since that seems 
> to be how libc++ is deciding where to put the library? ( 
> https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/libcxx/CMakeLists.txt#L424
>  
> 
>  ) at least on non-apple :/ (or maybe there's some way to make the connection 
> between the two less brittle - for libc++'s build to export some variable 
> that lldb can use, or for LLVM to provide something for both to use?)
> 
> Yeah, applying this change does work for me, but wouldn't work on Apple for 
> instance (where libcxx doesn't add the default target triple to the path):
> $ git diff
> diff --git lldb/test/API/lit.site.cfg.py.in  
> lldb/test/API/lit.site.cfg.py.in 
> index 987078a53edb..e327429b7ff9 100644
> --- lldb/test/API/lit.site.cfg.py.in 
> +++ lldb/test/API/lit.site.cfg.py.in 
> @@ -3,7 +3,7 @@
>  co