Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

relative refstring.h include in libcxxabi makes too strong assumptions #48657

Closed
nico opened this issue Feb 22, 2021 · 5 comments
Closed

relative refstring.h include in libcxxabi makes too strong assumptions #48657

nico opened this issue Feb 22, 2021 · 5 comments
Labels
bugzilla Issues migrated from bugzilla libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.

Comments

@nico
Copy link
Contributor

nico commented Feb 22, 2021

Bugzilla Link 49313
Resolution FIXED
Resolved on Feb 26, 2021 06:31
Version unspecified
OS Linux
CC @ldionne,@mclow,@rnk
Fixed by commit(s) https://reviews.llvm.org/rG72b18a86e11ebc970be96a8c2b11aa3a31c14c5d

Extended Description

a7b6574 (unreviewed? at least doesn't link to phab) adds this line to libc++abi's libcxxabi/src/stdlib_stdexcept.cpp:

+#include "../../libcxx/src/include/refstring.h"

This assumes a certain relative layout, which happens to not be the layout we have libc++ and libc++abi relative to in chromium. It's also not very easy to change things to give them that layout -- many third-party directories in chromium put code in "t_p/depname/src" (via a git submodules like thing) and then
put a build file in "t_p/depname".

We're trying to update our libc++abi now that we've successfully updated our libc++, and this is a problem.

We could add a random -I flag that this relative path resolves against. I'll do this for now, but it's a bit ugly. Maybe we can find something nicer to do on this bug.

Options:

  • say #include "refstring.h" and set up the include path in the build system
  • revert the change -- refstring.h has changed exactly once since that change, and that was likely the change motivating a7b6574 . Nothing else in libc++abi includes libcxx stuff, and that seems like a good thing layering-wise. The duplication is unfortunate, but maybe less unfortunate than a cyclic dep?h
@nico
Copy link
Contributor Author

nico commented Feb 22, 2021

Oh, https://reviews.llvm.org/D91359 adds an include of another internal header to refstring.h, so if we were to revert we'd have to copy that too. That doesn't seem great.

So maybe using #include "src/include/refstring.h" and adding the include search path in the build system is the least bad alternative? But the cyclic dep feels yucky too.

@nico
Copy link
Contributor Author

nico commented Feb 22, 2021

See also LIBCXXABI_LIBCXX_INCLUDES for a cmake toggle for the public includes.

@ldionne
Copy link
Member

ldionne commented Feb 22, 2021

Libc++ and libc++abi have required being built in a monorepo-like layout for a while now.

We have a strong desire to share more code between libc++ and libc++abi (in particular some CMake code), so I don't see us going back to allowing libc++/abi being built from arbitrary locations. Can you tell me a bit more about your setup?

If you're currently storing libc++ and libc++abi in t_p/libcxx/src and t_p/libcxxabi/src, one option would be to instead have something like t_p/llvm/src/{libcxx,libcxxabi}?

@nico
Copy link
Contributor Author

nico commented Feb 22, 2021

Libc++ and libc++abi have required being built in a monorepo-like layout for
a while now.

This is the only thing requiring this at the source level.

LIBCXXABI_STANDALONE_BUILD still exists, too.

We have a strong desire to share more code between libc++ and libc++abi (in
particular some CMake code), so I don't see us going back to allowing
libc++/abi being built from arbitrary locations. Can you tell me a bit more
about your setup?

Sure! We don't want to deps in all of llvm into our build, but only the runtime bits (actually, only libcxx, libcxxabi, and libunwind). So we have git mirrors of those subtrees. We then deps in each of these subtrees at t_p/depname/src and have a build file for each at t_p/depname/buildfile.

If you're currently storing libc++ and libc++abi in t_p/libcxx/src and
t_p/libcxxabi/src, one option would be to instead have something like
t_p/llvm/src/{libcxx,libcxxabi}?

That'd mean we can't independently roll libcxx, libcxxabi, and libunwind.

...would something like the following work for you? That keeps things basically the same upstream and makes things easier for us:

$ git diff
diff --git a/libcxxabi/src/CMakeLists.txt b/libcxxabi/src/CMakeLists.txt
index ff1e45705dca..8eca5185e0c0 100644
--- a/libcxxabi/src/CMakeLists.txt
+++ b/libcxxabi/src/CMakeLists.txt
@@ -57,6 +57,9 @@ endif()

include_directories("${LIBCXXABI_LIBCXX_INCLUDES}")

+# stdlib_stdexcept.cpp depends on libc++ internals.
+include_directories("${LIBCXXABI_LIBCXX_PATH}/src/include")
+
if (LIBCXXABI_HAS_CXA_THREAD_ATEXIT_IMPL)
add_definitions(-DHAVE___CXA_THREAD_ATEXIT_IMPL)
endif()
diff --git a/libcxxabi/src/stdlib_stdexcept.cpp b/libcxxabi/src/stdlib_stdexcept.cpp
index 4a464e48893d..66e6f14561ec 100644
--- a/libcxxabi/src/stdlib_stdexcept.cpp
+++ b/libcxxabi/src/stdlib_stdexcept.cpp
@@ -6,7 +6,6 @@
//
//===----------------------------------------------------------------------===//

-#include "../../libcxx/src/include/refstring.h"
#include "stdexcept"
#include "new"
#include
@@ -14,6 +13,9 @@
#include
#include

+// This is a file form libc++.
+#include "refstring.h"
+
static_assert(sizeof(std::__libcpp_refstring) == sizeof(const char *), "");

namespace std // purposefully not using versioning namespace

@nico
Copy link
Contributor Author

nico commented Feb 24, 2021

Uploaded basically that diff to https://reviews.llvm.org/D97379

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 11, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.
Projects
None yet
Development

No branches or pull requests

2 participants