Merging the libc++ and libc++abi repositories

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Merging the libc++ and libc++abi repositories

via cfe-dev
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.

[2] Fix for PR39051 - r242815
[3] Copying libc++'s new into libc++abi - r296787
[4] Duplicating more CMake configuration - r344191



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Merging the libc++ and libc++abi repositories

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 <[hidden email]> 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.

[2] Fix for PR39051 - r242815
[3] Copying libc++'s new into libc++abi - r296787
[4] Duplicating more CMake configuration - r344191


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Merging the libc++ and libc++abi repositories

via cfe-dev


On Thu, Oct 11, 2018 at 6:57 PM Richard Smith <[hidden email]> 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 <[hidden email]> 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.

[2] Fix for PR39051 - r242815
[3] Copying libc++'s new into libc++abi - r296787
[4] Duplicating more CMake configuration - r344191


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Merging the libc++ and libc++abi repositories

via cfe-dev


On Thu, Oct 11, 2018 at 8:49 PM Eric Fiselier <[hidden email]> wrote:


On Thu, Oct 11, 2018 at 6:57 PM Richard Smith <[hidden email]> 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 <[hidden email]> 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.

[2] Fix for PR39051 - r242815
[3] Copying libc++'s new into libc++abi - r296787
[4] Duplicating more CMake configuration - r344191


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Merging the libc++ and libc++abi repositories

via cfe-dev
In reply to this post by via cfe-dev


On Oct 11, 2018, at 17:49, Eric Fiselier via cfe-dev <[hidden email]> wrote:



On Thu, Oct 11, 2018 at 6:57 PM Richard Smith <[hidden email]> 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

I don't think that's the right order of changes.  It seems like a Git monorepo should come before introducing a dependency between repos.

On the other hand, I don't see a fundamental problem with nesting libcxxabi inside of libcxx.

On Wed, 10 Oct 2018 at 17:05, Eric Fiselier via cfe-dev <[hidden email]> 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.

[2] Fix for PR39051 - r242815
[3] Copying libc++'s new into libc++abi - r296787
[4] Duplicating more CMake configuration - r344191


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Merging the libc++ and libc++abi repositories

via cfe-dev
In reply to this post by via cfe-dev

On Oct 10, 2018, at 17:05, Eric Fiselier <[hidden email]> 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.

Maybe the problem is instead that libc++abi _was_ relying on internals of libc++? It’s not clear to me this would be solved by moving the code closer to each other.


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

What’s the rationale for needing that code in both libc++ and libc++abi?


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]

Fair enough.


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++?
Why does libc++abi require libc++? It seems like this is a rather unfortunate circular dependency.

I don’t know whether I’m in favor of this move or not. I’m certainly seeing the cost that Eric is depicting, and I’m paying for it, but I need to better understand why things are the way they are currently before formulating an opinion.

Louis


I look forward to the discussion this generates.

[2] Fix for PR39051 - r242815
[3] Copying libc++'s new into libc++abi - r296787
[4] Duplicating more CMake configuration - r344191




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev