<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1442534047;
        mso-list-template-ids:-769905498;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">+1<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">The only time I’ve needed to build libc++abi without libc++ was when I was testing libc++abi, and `ninja c++abi` was sufficient in the past, and would presumably be sufficient in the future to accomplish that goal.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> cfe-dev <cfe-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>Eric Fiselier via cfe-dev<br>
<b>Sent:</b> Wednesday, October 10, 2018 7:05 PM<br>
<b>To:</b> clang developer list <cfe-dev@lists.llvm.org>; libcxx-dev@lists.llvm.org<br>
<b>Cc:</b> Marshall Clow <mclow.lists@gmail.com><br>
<b>Subject:</b> [cfe-dev] Merging the libc++ and libc++abi repositories<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi All,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Before I go any further, I want to clarify what I'm NOT PROPOSING.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt">The Problem</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt">==========</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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++.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The goal of the merge is to prevent bugs like this from happening in the future.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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].<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt">Solutions</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt">=======</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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++.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There are some open questions:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt;mso-list:l0 level1 lfo1">
Should we create a new repository for this purpose? Or is it better to use libc++ as shared home (I vote for using libc++).<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt;mso-list:l0 level1 lfo1">
Should we do the same for libunwind?<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
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++?<o:p></o:p></li></ol>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I look forward to the discussion this generates.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_PR39051&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=_po4EvjVUD2KYboKJP4Svg2nlBCJJFpxFRLRmbyPF38&s=bTanv9lN5I2LZ6s9fsV5fjUqp9g6qA5SwJt_zvmr5XE&e=">
llvm.org/PR39051</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[2] Fix for PR39051 - <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_llvm-2Dmirror_libcxxabi_commit_ed902ff267148f3d76d33283766613056f57a06f&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=_po4EvjVUD2KYboKJP4Svg2nlBCJJFpxFRLRmbyPF38&s=y79kChe0NiiAyDZKSMHG1I-QkzeB6f0Fd7h2xgUjRUY&e=">r242815</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[3] Copying libc++'s new into libc++abi - <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_llvm-2Dmirror_libcxxabi_commit_4bf15a00704552100c7ffcf92e93c8d3414c9b50&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=_po4EvjVUD2KYboKJP4Svg2nlBCJJFpxFRLRmbyPF38&s=iodolun72i3hyrljU9mC1yNJ6rosKIJirQ36MbzYHsU&e=">r296787</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[4] Duplicating more CMake configuration - <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_llvm-2Dmirror_libcxxabi_commit_6d635f5765e76c66d31a26cb4d5d5e802e274b4f&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=_po4EvjVUD2KYboKJP4Svg2nlBCJJFpxFRLRmbyPF38&s=R9yLR_7KB9dkSB-pI0HuzIwQG5r3BRn3XGXC4chJEiQ&e=">
r344191</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>