[oi-dev] Transitioning from Sun Studio to gcc & clang/llvm

[Albert Lee]

On Mon, May 23, 2011 at 11:22 AM, Alasdair Lumsden <alasdairrr at gmail.com> wrote:
> Hi Albert,
>
> Thanks for the feedback, partial answers inline below!
>
> On 23 May 2011, at 16:05, Albert Lee wrote:
>> Should we be linking libgcc statically (apparently adds on the order
>> of 10k to every binary) or will every application depend on a package
>> with the gcc libraries?
>
> Still open for discussion - what are you/others thoughts? Beyond just the on-disk size, there's the in-memory size and presumably a performance difference.
>

It's mostly for math routines that the compiler didn't feel like
inlining, as well as exception handling for some languages [1]. There
may be a cache benefit from having a single copy in memory.

>>> 2. Follow the library layout guidelines set down by SFE
>>> 3. Compile gcc to use Sun ld, but GNU as
>>> 4. Use libstdc++ only where localisation is not affected
>>
>> libstdc++'s ABI is quite volatile, which can lead to a sad trail of
>> objects with incompatible ABI versions, and all software depending on
>> it will have to be rebuilt.
>
> This is why the gcc version supplied will be fixed for a 5+ year period - I doubt we'll be changing the gcc version any time soon after doing this. When we do update to a newer GCC or to llvm/clang or another compiler, we can continue to supply the library, via a compat package.
>
> So I don't see this as an issue, unless I've missed something.
>

If we have any application binaries we wish to support beyond that N
year period, this means keeping around a parallel world of of C++
libraries for them to depend on (SFE uses /usr/gnu for this). This may
be unavoidable independent of the choice of libstdc++ if we transition
to e.g. libc++ anyway, though.

>>> 5. Compile and supply llvm/clang
>>
>> And libc++?
>
> Yes, I don't see why not.
>
>>> 6. Ensure software we transition from Sun Studio compiles with both gcc and llvm/clang
>>> 7. Use gcc as the shipping default with a view to switching to llvm/clang at a future date, but allow either to be picked easily when it achieves performance and feature parity
>>>
>>> We can begin this process by applying the policy on new software we add to OI. How we transition our core consolidations can be discussed later on.
>>>
>>> If anyone has any serious objections to the above, let me know, otherwise I'll get this written up on the wiki as a policy.
>>>
>>
>> This will cause problems with tools, possibility impacting debugging.
>
> Could you elaborate a little bit more on this?
>

Are we going to try to finish the effort started by Rich to port the
gcc 3.4 changes to 4.x? I believe the most important ones for us are
to add argument saving (for mdb at least, maybe pstack).

>> This also affects illumos builds as g++ and libgcc-linked objects will be
>> involved.
>
> Again, could you go into more detail?
>

This will need testing, but the bits of C++ software in illumos which
will most likely be a non-issue if they continue to be built with
Studio (as I don't believe any of them have direct external
consumers). There may be dependencies on external C++ libraries,
hopefully very limited.

libgcc_s may be accidentally pulled in when linking some objects.

>> Will SPARC support require the gccfss patches?
>
> Are you proposing we use the GCC frontend with Sun Studio backend for SPARC? Or is there a patch set for GCC that improves patch support, from the gccfss source?
>

There are changes for correct SPARC code generation which I believe
introduced in gccfss.

> Anything that will cause an issue can be kept Sun Studio for now. It would be good to have a list of things that will b0rk or have potential issues.
>

[1] http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html