Re: [PATCH] Real fix for AIX exception handling

[David Edelsohn <dje dot gcc at gmail dot com>]

On Wed, Mar 29, 2017 at 3:50 PM, Jeff Law <law@redhat.com> wrote:
> On 03/27/2017 09:41 AM, David Edelsohn wrote:
>>>
>>> As far as I have discovered, the real problem with AIX exception handling
>>> is
>>> that the exception landing pads are symbols that must not (but still are)
>>> exported from shared libraries - even libstdc++.
>>>
>>> I'm wondering if attached libtool(!)-patch would fix even that GDB
>>> problem
>>> once applied to each(!) shared library creation procedure.
>>>
>>> However, each workaround still applies as long as there's a single shared
>>> library involved that has not stopped exporting these symbols yet.
>>>
>>> Thoughts?
>>>
>>> Maybe gcc's collect2 should apply this additional symbol filter itself
>>> calling (AIX) ld, rather than leaving this to each build system?
>>>
>>> * m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates
>>> _GLOBAL__ symbols as, amongst others, landing pads for C++ exceptions.
>>> These symbols must not be exported from shared libraries, or exception
>>> handling may break for applications with runtime linking enabled.
>>
>>
>> Hi, Michael
>>
>> Thanks for the analysis.
>>
>> The problem with EH for GDB involves static linking, not runtime
>> linking.
>
> That seems to be my understanding as well.
>
>> And there seems to be different behavior for GCC 4.8 and GCC
>> 4.9.
>
> Could it perhaps be an IPA issue -- we know IPA can change symbol
> scope/linkage  in some cases.  Maybe it's mucking things up.  Is there more
> detail in a thread elsewhere on this issue?

The problem is GCC EH tables and static linking.  libstdc++ and the
main application are ending up with two separate copies of the tables
to register EH frames.

Static linking worked in GCC 4.8, but not in GCC 4.9.  I have been
trying to understand what changed and if GCC 4.8 worked by accident.

Note that AIX does not install a separate libstdc++ static archive and
instead statically links against the shared object.  libstdc++
apparently uses the EH table referenced when it was bound by collect2
and the application uses the one created when the executable is
created -- the libgcc_eh.a solution doesn't work.  Again, the question
is why this apparently functioned correctly for GCC.4.8.

There was a change to constructor order around that time and that may
have affected where EH frames were recorded.

Thanks, David