On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwallner <michael.haubenwall...@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