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

[Eric Fiselier via cfe-dev]

On Thu, Oct 11, 2018 at 6:57 PM Richard Smith <richard at metafoo.co.uk> wrote:

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

Moving to a mono-repository alone would address most of the code
sharing/duplication problems.
And if the move is forseeable, we could start the process now by making
libc++abi require that libc++
is checked out next to it.

/Eric


> 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/9b0af211/attachment.html>