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

[Eric Fiselier via cfe-dev]

On Thu, Oct 11, 2018 at 8:49 PM Eric Fiselier <eric at efcs.ca> wrote:

>
>
> 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.
>

To clarify, the monorepo only helps if we *require* users to check out the
monorepo, and don't allow
libc++ or libc++abi subproject mirrors.

>
> /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/0545e893/attachment.html>