[cfe-dev] Merging the libc++ and libc++abi repositories
Eric Fiselier via cfe-dev
cfe-dev at lists.llvm.org
Thu Oct 11 17:57:13 PDT 2018
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>
>> 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.
>> 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 . 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
>>> 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 .
>>> 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. 
>>> 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.
>>>  llvm.org/PR39051
>>>  Fix for PR39051 - r242815
>>>  Copying libc++'s new into libc++abi - r296787
>>>  Duplicating more CMake configuration - r344191
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev