compiler-rt is now not only a libgcc replacement for different platforms, there are sanitizer and profile runtimes as well. I plan to move the files as follows during this week:
libraries:
a) all libgcc replacement stuff moves from “/lib” to “/lib/core” (the name sucks, please suggest alternatives). Same for platform-specific code: “/lib/arm/”->“/lib/core/arm”, “/lib/i386”->“/lib/core/i386” etc.
b) “/BlocksRuntime”->“/lib/BlocksRuntime”
c) “/lib/sanitizer_common”, “/lib/xsan”, “/lib/profile” are not moved.
tests:
all tests (lit tests and unit tests) are moved from directories under “/lib” to “/test” to be consistent with LLVM/Clang test subtrees.
I would still urge folks to consider keeping distinct functionality in separate places.
Agreed, it makes more sense for the [language agnostic] unwinder to be in compiler-rt than libcxxabi -- but IMO it makes even more sense for it to be distinct.
The bundling of the unwinder with libgcc_s gave us (i.e. 3rd party folks, outside the vendor's organisation) nothing but headaches. Much happier to see it in libunwind.xxx
Given that the consensus appeared to be that this is where it belongs... why not? It seems strange to do a big reorganisation pass, but not do all of it.
I would still urge folks to consider keeping distinct functionality in separate places.
Agreed, it makes more sense for the [language agnostic] unwinder to be in compiler-rt than libcxxabi -- but IMO it makes even more sense for it to be distinct.
The question of the repository it belongs in is separate from the question of how it's built. In FreeBSD, the code is likely to remain in a library that's called libgcc_s.so or libgcc_eh.a, as that's required for backwards compatibility.
The bundling of the unwinder with libgcc_s gave us (i.e. 3rd party folks, outside the vendor's organisation) nothing but headaches. Much happier to see it in libunwind.xxx
I'd be interested to hear what these headaches are, to see if we can avoid them in the future.
The bundling of the unwinder with libgcc_s gave us (i.e. 3rd party folks, outside the vendor's organisation) nothing but headaches. Much happier to see it in libunwind.xxx
I'd be interested to hear what these headaches are, to see if we can avoid them in the future.
A system B is built with compiler Version X.Y .. it is released with several (maybe many) libraries &| frameworks linked to the unwinder in the rt from compiler x.y.
Later, one wishes to distribute code built with compiler P.Q which now has a different rt version, perhaps with enhancements. However you cannot duplicate the unwinder (current design require a process-wide single unwinder). So you're stuck with (a) not being able to use system libs already linked with the old unwinder or (b) replacing the old rt+unwinder with a new one.
For some systems (b) might be acceptable - but, in general, it is not (esp. if the system is in the category of, for example, OSX). It makes it very difficult for a user of a 3rd party compiler to deliver code to run on such a system without jumping through tortuous hoops.
(a) is sometimes acceptable for stand-alone c/l or deamon code - but it's generally a non-starter for anything using a gui or having other wide linkage with the base system.
I suppose that these issues are lesser for systems where updating core components might be done at whim by the end-user, but even there it still seems to make control over releases/security less than satisfactory.
There are work-arounds, but they represent considerable bloat if one only wants to supply an application to run on system B, but built with an un-to-date compiler. This is quite aside from the security implications of replacing the system's unwinder simply to get access to an app built with a newer compiler.
As it happens, I’ve already started massaging libunwind to make it a part of compiler-rt.
At the moment, I am shooting for the makefile build. Once that’s done, I could use somebody’s help to add it to cmake build system.
It would be nice if somebody could look into disentangling compiler-rt from clang. I think that at the least it should be build-able together with LLVM (i.e. by checking it out into llvm/projects) without clang involvement. Completely standalone builds would be a plus, if feasible.
Last but not the least: I still haven’t heard anybody admitting to being a maintainer of compiler-rt Somebody will need to review the patch and check it in…
As it happens, I've already started massaging libunwind to make it a part
of compiler-rt.
At the moment, I am shooting for the makefile build. Once that's done, I
could use somebody's help to add it to cmake build system.
It would be nice if somebody could look into disentangling compiler-rt
from clang. I think that at the least it should be build-able together
with LLVM (i.e. by checking it out into llvm/projects) without clang
involvement. Completely standalone builds would be a plus, if feasible.
Yes, this would be nice to have. I hope to address this some day.
Last but not the least: I still haven't heard anybody admitting to being a
maintainer of compiler-rt Somebody will need to review the patch and
check it in...
+Daniel
I think I can sign up for this. I can review the CMake integration. I don't
really understand Makefile-based build, though.