[llvm-dev] [RFC] One or many git repositories?
Renato Golin via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 21 13:55:42 PDT 2016
On 21 July 2016 at 18:12, Justin Lebar <jlebar at google.com> wrote:
> llvm, clang, clang-tools-extra, lld, polly, lldb, llgo, compiler-rt,
> openmp, and parallel-libs.
I really, *really* would like to see libc++ / abi / unwind. :)
My reason is that, when building toolchains, the C++ ABI and unwinding
are fundamental parts of the run-time library, of which RT is only
RT has the builtins (and a lot of other stuff), but it can't unwind on
its own. So debuggers (LLDB), profilers (which lives in RT) and basic
stack traces don't work, unless you use an alternative option (like
libgcc). This is *specially* true for ARM.
When unwinding C++ code, one needs cxa_* functions, and that's in
libc++abi, which interoperates with libc++, unwind and RT.
The LLVM triple abi/unwind/RT is not divided in the same way as
gcc_eh/gcc_s/gcc, so picking some but not others is not a sane option.
Plus, validating every possible choices needs one buildbot for each
combination, which is not feasible, at least not for us.
Basically, picking RT and not unwind/abi breaks their
inter-dependencies, so does picking abi but not libc++.
> Projects that don't depend on a specific version of llvm or some other
> subproject -- test-suite and libc++ -- are not included. Everything
> else is, because the whole idea is to have one repository that
> captures the implicit versioning dependencies between (say) lldb and
I'm fine with the test-suite not being in the core, but the others
will make it very hard to build actual toolchains.
They're also reasonably small, rarely updated and self-contained, so I
don't see why they can't be there.
More information about the llvm-dev