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

[David Edelsohn <dje.gcc@gmail.com>]

Michael,

Why does the configure change match with p*-*-aix... instead of power*
or powerpc*?  Yes, it's unique and will match, but why make it as
short as possible, which doesn't match other uses?

In your documentation, how are you distinguishing between Dynamic
Linking and Runtime Linking?

Thanks, David


On Mon, Nov 10, 2014 at 12:41 PM, Michael Haubenwallner
<michael.haubenwallner@ssi-schaefer.com> wrote:
>
>
> 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/