Heads-up: changing the structure of compiler-rt source tree

Hi all,

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:

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

  2. tests:
    all tests (lit tests and unit tests) are moved from directories under “/lib” to “/test” to be consistent with LLVM/Clang test subtrees.

See the original mail from Chandler for the overview of compiler-rt tree current state and suggestion to change its structure:
http://clang-developers.42468.n3.nabble.com/Sanitizers-libs-in-Compiler-RT-tp4037520p4037567.html

Please speak up if you disagree with this.

Hi Alexey,

"rt" could be an alternative to "core", but really, either are equally bad. :slight_smile:

LGTM either way.

cheers,
--renato

Maybe just lib/runtime (assuming that "rt" was shorthand for it)? :slight_smile:

-Dimitry

According to the makefile, the module is called “builtins”, perhaps the directory should be called the same?

Yes, I think “builtins” makes more sense than “runtime” or “core”. Thanks for suggestion!

Are you going to move the unwind library there as part of the reorganisation?

David

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

Iain

Are you going to move the unwind library there as part of the
reorganisation?

No.

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.

David

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.

David

Hi David,

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.

cheers
Iain

Isn't this true for every Linux/BSD system?

--renato

Hi David,

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 :slight_smile: Somebody will need to review the patch and check it in…

Vadim

+Nick, who has been looking at similar things recently.

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 :slight_smile: 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.

Trying again since apparently I suck at email…