Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s

[David Edelsohn <dje dot gcc at gmail dot com>]

On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwallner
<michael.haubenwallner@ssi-schaefer.com> wrote:
>
> Am 2014-11-07 20:52, schrieb David Edelsohn:
>> First, please explicitly copy me on AIX or PowerPC patches sent to gcc-patches.
>>
>> I don't have a fundamental objection to including this option, but
>> note that Richi, Honza and I have discovered that using AIX runtime
>> linking option interacts badly with some GCC optimizations and can
>> result in applications that hang in a loop.
>
> Feels like adding the "aix-soname" linking procedure becomes more important:
>
>> All code on AIX is position independent (PIC) by default.  Executables
>> and shared libraries essentially are PIE.  Because of this, AIX does
>> not provide separate "static" libraries and one can link statically
>> with a shared library.
>>
>> Creating a library enabled for runtime linking with -G (-brtl), causes
>> a lot of problems, including a newly recognized failure mode.  Without
>> careful control over AIX symbol export, all global calls with use
>> glink code (equivalent to ELF PLTs). This also creates a TOC entry for
>> every global call, possibly overflowing the TOC.
>
> About to define "careful control over AIX symbol export":
> The symbols listed in the import file are those found in the object files
> only, not the ones created at linktime (like __GLOBAL*) or from the static
> objects found in libc.a. While I do this in libtool from the beginning here,
> I have had a helper script wrapping ld to support '--soname=' for non-libtool
> packages, where creating the import file from the final shared object also
> included static libc-provided symbols, which turned out as dependency pitfall.

AIX added ELF-like visibility support to XCOFF, which would be
preferred.  Except it was not added in a formal release, like AIX 8.1
and apparently was back-ported to at least AIX 6.1, so its difficult
to phase in the support. One would need to add a configure test for
the feature and not all users are upgrading the system. So one cannot
build and distribute "GCC for AIX 7.1" and know the feature is
available in the system tools.  GCC builds would be incompatible and
object files, libraries, executables created by GCC would be
incompatible.  Basically, a mess.

> While I haven't focussed on nor explicitly tested, I do believe that this
> also solves problems with global C++ constructor/destructor call orders.

Why? There still is the problem of the AIX kernel runtime loader
ordering dependent shared objects.

>> But the main problem is GCC uses aliases and functions declared as
>> weak to support some C++ features.
>
> This is another reason why I do force runtime linking for our application,
> which uses these C++ features while its main target platform is Linux.

You have not explained how this has any fix / benefit affecting the
problem, other than separate shared and static libraries.  Forcing
runtime linking seems irrelevant.  It was linking shared before and
linking shared after your patch (with runtime linking) so the net
effect is zero.

Again, runtime linking of all global symbols affects performance and
bloats the TOC, making TOC overflow more likely.

I don't have a fundamental objection to the patch, but you have not
really responded to the potential problems and any motivation for this
feature other than greater SVR4 emulation.  For better or worse, AIX
is not SVR4.  Every library built with this option hurts performance
on AIX and potentially causes mysterious TOC overflow errors, which
confuse users unfamiliar with AIX and whose workarounds hurt
performance even more.

Thanks, David