On 02/10/2016 02:27 PM, David Edelsohn wrote: > On Wed, Feb 10, 2016 at 1:52 AM, Michael Haubenwallner > <michael.haubenwall...@ssi-schaefer.com> wrote: >> >> On 02/08/2016 02:59 PM, David Edelsohn wrote: >>> Runtime linking is disabled by default on AIX, and I disabled it for >>> libstdc++. >> >> For large applications mainly developed on/for Linux I do prefer/need >> runtime linking even on AIX. Still I do believe there is no AIX-based >> reason to leave runtime linking disabled, but build-/linktime issues >> instead that cause things to fail with runtime linking enabled. > > What do you mean by the term "runtime linking"? Runtime linking means > runtime overloading of symbols -- preloading -- not dynamic linking > and loading. dlopen does not require runtime linking. There also are > issues with searching for shared objects with .a or .so file > extension, but that can be addressed separately.
We're actually talking about the same "runtime linking" understanding. > Runtime linking causes every global, exported function call to be > invoked through indirect glue code. And each function must be > inserted into the TOC. The indirect call overhead is very expensive, > and potential TOC overflow can cause even more performance > degradation. Well, I'm in the lucky situation to not need to care for performance that much. Don't get me wrong - I don't want to change any default settings, but keep symbol-overloading at runtime just working if requested for the final executable (by linking with -brtl). What I indeed do not know: Is the performance overhead still active even when the final executable is _not_ linked with -brtl, but the shared libraries only are linked with -G ? > Your statement of no AIX-based reason to leave runtime linking > disabled is fundamentally flawed. Agreed performance wise. But still I fail to see a functional reason. >>> There are two remaining issues: >>> >>> 1) FDEs with overlapping ranges causing problems with exceptions. I'm >>> not sure of the best way to work around this. Your patch is one >>> possible solution. >> >> This patch is not meant as a final solution, but to improve current >> situation with broken build systems exporting even _GLOBAL__ symbols. >> I'm about to prepare another libtool patch to fix that one. >> >>> 2) AIX linker garbage collection conflicting with scanning for >>> symbols. collect2 scanning needs to better emulate SVR4 linker >>> semantics for object files and archives. >> >> Probably collect2 should filter the symbol list originating in either >> an explicit -bexport:file or the -bexpall/-bexpfull flags and pass the >> resulting symbol list as explicit -bexport:file only to the AIX linker? > > -bexpall and -bexpfull cause numerous problem by re-exporting symbols. > > All of the suggestions will produce programs that function, but have > severe performance impacts and unintended consequences that you seem > to be ignoring. Erm... I don't think so - what I mean is: Probably collect2 should _not_ passthrough the -bexpall/-bexpfull/-bexport:file flags to the linker, but itself create an export file and pass this one _instead_. However, this feels like a workaround for broken build systems - which do provide the breaking -bexp* flags to gcc (collect2) already. Thanks! /haubi/ > > - David > >> >> /haubi/ >> >>> >>> Thanks, David >>> >>> >>> On Mon, Feb 8, 2016 at 7:14 AM, Michael Haubenwallner >>> <michael.haubenwall...@ssi-schaefer.com> wrote: >>>> Hi David, >>>> >>>> still experiencing exception-not-caught problems with gcc-4.2.4 on AIX >>>> leads me to some patch proposed in http://gcc.gnu.org/PR13878 back in >>>> 2004 already, ought to be fixed by some different commit since 3.4.0. >>>> >>>> As long as build systems (even libtool right now) on AIX do export these >>>> _GLOBAL__* symbols from shared libraries, overlapping frame-base address >>>> ranges may become registered, even if newer gcc (seen with 4.8) does name >>>> the FDE symbols more complex to reduce these chances. >>>> >>>> But still, just think of linking some static library into multiple shared >>>> libraries and/or the main executable. Or sometimes there is just need for >>>> some hackery to override a shared object's implementation detail and rely >>>> on runtime linking to do the override at runtime. >>>> >>>> Agreed both is "wrong" to some degree, but the larger an application is, >>>> the higher is the chance for this to happen. >>>> >>>> Thoughts? >>>> >>>> Thanks! >>>> /haubi/
