Re: libgcc: On AIX, increase chances to find landing pads for exceptions

[Michael Haubenwallner <michael dot haubenwallner at ssi-schaefer dot com>]

On 02/10/2016 02:27 PM, David Edelsohn wrote:
> On Wed, Feb 10, 2016 at 1:52 AM, Michael Haubenwallner
> <michael.haubenwallner@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.haubenwallner@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/