Michael137 wrote: > > 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 https://github.com/llvm/llvm-project/pull/113935 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
