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

[David Blaikie via lldb-dev]

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/20211020/b3556351/attachment.html>