This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
- From: Michael Haubenwallner <michael dot haubenwallner at ssi-schaefer dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 10 Nov 2014 18:41:19 +0100
- Subject: Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnynSPN4aAugugjVhZCOBBzTLpVw4VoZGFkef+nQqKAkFWQ at mail dot gmail dot com> <54608C8C dot 9050605 at ssi-schaefer dot com> <CAGWvnymNGmWYe0aeKAPfa-qNGK2YG0-Y=KQs5oCHtnHGHbRJyA at mail dot gmail dot com>
Am 2014-11-10 17:06, schrieb David Edelsohn:
> 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.
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/