[lldb][test] Skip libc++ tests if it is linked statically

[dzhidzhoev]

Some tests from 'import-std-module' used to fail on the builder
https://lab.llvm.org/staging/#/builders/195/builds/4470, since libcxx is
set up to be linked statically with test binaries on it.

Thus, they were temporarily disabled in #112530. Here, this commit is
reverted.

When libcxx is linked with a program as an archive of static libraries,
functions that aren't used in the program are omitted. Then, jitted
expressions from the tests try calling several functions
that aren't present in the process image, which causes the failure.

LLD (and GNU ld AFAIK) links a binary with libcxx shared library
if libc++.so is present in corresponding library search paths.
Otherwise, it tries static linking. Here, a linker flag is added
to a clang call in libcxx tests configuration, which ensures that
libc++.so is present and found by linker.

Forcing linker to keep all functions from libcxx archive in this way #98701,
without checking whether libcxx is linked statically looks like a less
clean solution, but I'm not sure about that.

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Vladislav Dzhidzhoev (dzhidzhoev)

Changes

Some tests from 'import-std-module' used to fail on the builder
https://lab.llvm.org/staging/#/builders/195/builds/4470, since libcxx is
set up to be linked statically with the binary on it.

Thus, they were temporarily disabled in #112530. Here, this commit is
reverted.

When libcxx is linked with a program as an archive of static libraries,
functions that aren't used in the program are omitted. Then, jitted
expressions from the tests try calling several functions
that aren't present in the process image, which causes the failure.

LLD (and GNU ld AFAIK) links a binary with libcxx shared library
if libc++.so is present in corresponding library search paths.
Otherwise, it tries static linking. Here, a linker flag is added
to a clang call in libcxx configuration, which ensures that
libc++.so is present and found by linker.

Forcing linker to keep all functions from libcxx archive in this way #98701,
without checking whether libcxx is linked statically looks like a less
clean solution, but I'm not sure about that.

---

Full diff: https://github.com/llvm/llvm-project/pull/113935.diff

4 Files Affected:

• (modified) lldb/packages/Python/lldbsuite/test/dotest.py (+1-1)
• (modified) lldb/test/API/commands/expression/import-std-module/array/TestArrayFromStdModule.py (-1)
• (modified) lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/TestDbgInfoContentVectorFromStdModule.py (-1)
• (modified) lldb/test/API/commands/expression/import-std-module/vector-of-vectors/TestVectorOfVectorsFromStdModule.py (-1)

diff --git a/lldb/packages/Python/lldbsuite/test/dotest.py b/lldb/packages/Python/lldbsuite/test/dotest.py
index 681ea1638f2d6f..46673a9886c57e 100644
--- a/lldb/packages/Python/lldbsuite/test/dotest.py
+++ b/lldb/packages/Python/lldbsuite/test/dotest.py
@@ -776,7 +776,7 @@ def canRunLibcxxTests():
 
     if platform == "linux":
         with tempfile.NamedTemporaryFile() as f:
-            cmd = [configuration.compiler, "-xc++", "-stdlib=libc++", "-o", f.name, "-"]
+            cmd = [configuration.compiler, "-xc++", "-stdlib=libc++", "-l:libc++.so", "-o", f.name, "-"]
             p = subprocess.Popen(
                 cmd,
                 stdin=subprocess.PIPE,
diff --git a/lldb/test/API/commands/expression/import-std-module/array/TestArrayFromStdModule.py b/lldb/test/API/commands/expression/import-std-module/array/TestArrayFromStdModule.py
index bafc7628296217..13ab6b0c9ac1fb 100644
--- a/lldb/test/API/commands/expression/import-std-module/array/TestArrayFromStdModule.py
+++ b/lldb/test/API/commands/expression/import-std-module/array/TestArrayFromStdModule.py
@@ -10,7 +10,6 @@
 class TestCase(TestBase):
     @add_test_categories(["libc++"])
     @skipIf(compiler=no_match("clang"))
-    @skipIfLinux  # https://discourse.llvm.org/t/lldb-test-failures-on-linux/80095
     def test(self):
         self.build()
 
diff --git a/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/TestDbgInfoContentVectorFromStdModule.py b/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/TestDbgInfoContentVectorFromStdModule.py
index 71eaeef20e792d..1c32222e64f14c 100644
--- a/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/TestDbgInfoContentVectorFromStdModule.py
+++ b/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/TestDbgInfoContentVectorFromStdModule.py
@@ -14,7 +14,6 @@ class TestDbgInfoContentVector(TestBase):
     @skipIf(compiler="clang", compiler_version=["<", "12.0"])
     @skipIf(macos_version=["<", "14.0"])
     @skipIfDarwin  # https://github.com/llvm/llvm-project/issues/106475
-    @skipIfLinux  # https://discourse.llvm.org/t/lldb-test-failures-on-linux/80095
     def test(self):
         self.build()
 
diff --git a/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/TestVectorOfVectorsFromStdModule.py b/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/TestVectorOfVectorsFromStdModule.py
index e9415fd53651f7..a1f33271f39d2f 100644
--- a/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/TestVectorOfVectorsFromStdModule.py
+++ b/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/TestVectorOfVectorsFromStdModule.py
@@ -10,7 +10,6 @@
 class TestVectorOfVectors(TestBase):
     @add_test_categories(["libc++"])
     @skipIf(compiler=no_match("clang"))
-    @skipIfLinux  # https://discourse.llvm.org/t/lldb-test-failures-on-linux/80095
     def test(self):
         self.build()
 

[github-actions]

✅ With the latest revision this PR passed the Python code formatter.

[labath]

I don't think this is the right solution. Most of the libc++ tests (and tests in general) run just fine with a static c++ library, and they shouldn't be penalized because of a few outliers (that nobody wants to support properly).

I still believe the right fix is to make sure the tests pull in the symbols they want to use. I'm certain there are ways to pull the required libc++ symbols without pulling in the (debug info for) libc++ we don't want to be present there.

[Michael137]

Agree with Pavel.

When libcxx is linked with a program as an archive of static libraries,
functions that aren't used in the program are omitted.

This really isn't the problem. The tests want those symbols to not be present and make sure that we can find those in the std Clang module. So I'm pretty sure the issue isn't about what symbols get stripped from the library

[labath]

Agree with Pavel.

I'm not sure you do :P

When libcxx is linked with a program as an archive of static libraries,
functions that aren't used in the program are omitted.

This really isn't the problem. The tests want those symbols to not be present and make sure that we can find those in the std Clang module. So I'm pretty sure the issue isn't about what symbols get stripped from the library

There are different kinds of symbols going around here. The symbol you don't want to be in the binary is std::vector<T>::at() (because it can be generated from the c++ module and stuff). However, the implementation of at() will call (on the failure path) __libcxx_throw_out_of_range (or something, I forgot it's name), which is a non-template function defined only in some libc++ source (not header) file. The libc++ module will not contain a definition of that. And if the program never calls it, the symbol won't be extracted from the archive. I think the fix is to make sure this function is present (by depending on it in some way), without pulling in std::vector and friends.

[Michael137]

Agree with Pavel.

I'm not sure you do :P

When libcxx is linked with a program as an archive of static libraries,
functions that aren't used in the program are omitted.

This really isn't the problem. The tests want those symbols to not be present and make sure that we can find those in the std Clang module. So I'm pretty sure the issue isn't about what symbols get stripped from the library

There are different kinds of symbols going around here. The symbol you don't want to be in the binary is std::vector<T>::at() (because it can be generated from the c++ module and stuff). However, the implementation of at() will call (on the failure path) __libcxx_throw_out_of_range (or something, I forgot it's name), which is a non-template function defined only in some libc++ source (not header) file. The libc++ module will not contain a definition of that. And if the program never calls it, the symbol won't be extracted from the archive. I think the fix is to make sure this function is present (by depending on it in some way), without pulling in std::vector and friends.

Ah I see, thanks for elaborating! Yea that makes sense. Referencing __throw_out_of_range somehow might work. Or just change the function we're calling from at to something that doesn't pull in the symbol from the dylib? That should still provide us with coverage of calling functions from the std module

[labath]

Or just change the function we're calling from at to something that doesn't pull in the symbol from the dylib? That should still provide us with coverage of calling functions from the std module

That might work too (depending on how good we/clang are at not importing the unused parts of the libc++ module).

[dzhidzhoev]

Thank you for the feedback! I was sorting out the ways to fix that.

IMO explicitly referencing symbols that are referenced implicitly from the library could work, but it would look obscure. I'd try again with the solution like this #98701: we'll make lldb-remote-* buildbots build all static libraries (libc++, libc++abi, libunwind) separately (so as not to use '--ignore-duplicate-members' flag) and manually link tests with the whole library so that all internal functions will be present in the binary.

#118986