Am 2014-11-10 17:06, schrieb David Edelsohn: > 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.
As I've seen the "weak" information on an older AIX 5.3 TL8 already: Is this visibility support something different than what "nm -l" or "nm -P" shows? >> 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. Feels like I indeed haven't digged deep enough into that topic yet: To be ignored here then. >>> 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. My main reason here is to allow for *filename*-based sharedlib versioning, which I haven't been able to achive without import files. In-archive versioning is a pita from a package manager's point of view. For a second reason: Due to its Linux-centric history (well, HP-UX and Solaris before), our application architecture does rely on runtime linking in some corner cases. This is why I force that for AIX in our development- and runtime-platform, which is similar to /opt/freeware/, but based on Gentoo Prefix. For a third reason (maybe I don't have deep enough insight as well): If I understand correctly, you switched to build libstdc++ without runtime linking, because of problems when linking statically against the rtl-enabled libstdc++, no? For this case, by incident "aix-soname" does prevent shared objects built with runtime linking from being statically linked. For another reason: I can imaging to provide an rtl_enable'd libc.so as well, to allow for easier use of memory debuggers that intercept the malloc/free &co libc calls... But AFAICT these rely on every sharedlib to be built with runtime linking enabled. > Again, runtime linking of all global symbols affects performance and > bloats the TOC, making TOC overflow more likely. Well, I don't have need to care for performance that much. So do I force -mminimal-toc as well, where the only reason I have seen so far to avoid the -bbigtoc linker flag instead is that gdb has problems with that. > 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. Looking more like SVR4 is nothing more than a nice side effect when doing filename-based shlib-versioning this proposed way, not a reason by itself. Which potential problems do you think of? I fail to find more pointers... Thanks! /haubi/
