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

[David Blaikie via lldb-dev]

+Louis Dionne <ldionne at apple.com> - 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 <dblaikie at gmail.com> wrote:

> On Tue, Oct 19, 2021 at 4:55 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> On Tue, Oct 19, 2021 at 9:08 AM Raphael Isemann <teemperor at gmail.com>
>> 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 <http://lit.site.cfg.py.in>
> lldb/test/API/lit.site.cfg.py.in <http://lit.site.cfg.py.in>*
>
> *index 987078a53edb..e327429b7ff9 100644*
>
> *--- lldb/test/API/lit.site.cfg.py.in <http://lit.site.cfg.py.in>*
>
> *+++ lldb/test/API/lit.site.cfg.py.in <http://lit.site.cfg.py.in>*
>
> @@ -3,7 +3,7 @@
>
>  config.llvm_src_root = "@LLVM_SOURCE_DIR@"
>
>  config.llvm_obj_root = "@LLVM_BINARY_DIR@"
>
>  config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
>
> -config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
>
> +config.llvm_libs_dir = "@LLVM_LIBS_DIR@/@LLVM_DEFAULT_TARGET_TRIPLE@"
>
>  config.llvm_shlib_dir = "@SHLIBDIR@"
>
>  config.llvm_build_mode = "@LLVM_BUILD_MODE@"
>
>  config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
>
> Thoughts?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20211025/2495a6a7/attachment.html>