[cfe-dev] Merging the libc++ and libc++abi repositories
Eric Fiselier via cfe-dev
cfe-dev at lists.llvm.org
Thu Oct 11 17:49:40 PDT 2018
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
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.
> 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