llvm dev - Feb 2014 - [LLVMdev] Heads-up: changing the structure of compiler-rt source tree

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

On 12 Feb 2014, at 12:56, David Chisnall wrote:
> Are you going to move the unwind library there as part of the
reorganisation?
> 
> David
> 
> On 11 Feb 2014, at 09:59, Alexey Samsonov <samsonov at google.com>
wrote:
> 
>> 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.
>> 
>> -- 
>> Alexey Samsonov, MSK
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 12 Feb 2014, at 13:11, Iain Sandoe <iain at codesourcery.com> wrote:
> 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,

On 12 Feb 2014, at 13:23, David Chisnall wrote:
> On 12 Feb 2014, at 13:11, Iain Sandoe <iain at codesourcery.com>
wrote:
> 
>> 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