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

[Iain Sandoe]

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