[cfe-dev] Merging the libc++ and libc++abi repositories

[Richard Smith via cfe-dev]

How do you see this interacting with the move to a git monorepository?

On Wed, 10 Oct 2018 at 17:05, Eric Fiselier via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi All,
>
> The status quo of libc++abi and libc++ requires the duplication of a lot
> of code and logic between the repositories, and often in ways that require
> the two be kept in perfect sync. As it stands now, this it too complicated.
> This email proposes putting libc++abi and libc++ into the same repository.
>
> Before I go any further, I want to clarify what I'm NOT PROPOSING.
>
> I'm NOT proposing removing support for using libsupc++, libstdc++, or
> libcxxrt  as the runtime library under libc++. I'm NOT proposing absorbing
> libc++abi into libc++; they will remain distinct entities. In summary, If
> you use libc++ or libc++abi in a weird configuration today, then that
> should continue to work after this change.
>
> The Problem
> ==========
>
> So why do I want to keep the two libraries together? Because the amount of
> duplication across libc++ and libc++abi is becoming unmaintainable, and
> that's causing bugs.
>
> For example, libc++abi shipped a serious regression in the 7.0 release
> which caused thrown exceptions to have the wrong alignment, and in turn
> caused programs to segfault. It was caused because libc++abi forgot to
> define _LIBCPP_BUILDING_LIBRARY like libc++ does [1][2]. In the above case
> a bug was caused because libc++abi depended on libc++ internals, but it was
> not kept in sync with changes to libc++.
>
> The goal of the merge is to prevent bugs like this from happening in the
> future.
>
> libc++ and libc++abi also contain duplicate versions of large amounts of
> code, including the cpp files which implement <new>, <stdexcept>,
> <exception>, and <typeinfo>. The versions in libc++ and libc++abi should be
> *the exact same*, but we're forced to keep them in separate repositories.
> This causes bugs where one version isn't updated when the other gets a new
> feature or a bug fix [3].
>
> Finally, libc++ and libc++abi could share almost all of their CMake and
> LIT configuration, but they don't. This introduces a serious but unneeded
> maintenance cost. Here's an example from today where the libc++ sanitizer
> configuration for Mac had to be copied into libc++abi verbatim. [4]
>
> Solutions
> =======
>
> I propose merging the libc++ and libc++abi repositories into one. The
> exact structure of this merged repository is TBD. For simplicity I'll
> assume we decide to move libc++abi INTO libc++.
>
> There are some open questions:
>
>
>    1. Should we create a new repository for this purpose? Or is it better
>    to use libc++ as shared home (I vote for using libc++).
>
>    2. Should we do the same for libunwind?
>
>    3. We want to be able to build libc++ w/o libc++abi, but is the
>    reverse true? Does anybody have an existing use case for building libc++abi
>    w/o libc++?
>
>
> I look forward to the discussion this generates.
>
> [1] llvm.org/PR39051
> [2] Fix for PR39051 - r242815
> <https://github.com/llvm-mirror/libcxxabi/commit/ed902ff267148f3d76d33283766613056f57a06f>
> [3] Copying libc++'s new into libc++abi - r296787
> <https://github.com/llvm-mirror/libcxxabi/commit/4bf15a00704552100c7ffcf92e93c8d3414c9b50>
> [4] Duplicating more CMake configuration - r344191
> <https://github.com/llvm-mirror/libcxxabi/commit/6d635f5765e76c66d31a26cb4d5d5e802e274b4f>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181011/c1d07936/attachment.html>