This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]