Re: [PATCH] Real fix for AIX exception handling

[Jeff Law <law@redhat.com>]

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 patch seems correct for the runtime linking case, but I don't
> believe that it solves all of the EH issues -- at least more
> explanation is needed.
The current libtool.m4 in GCC looks out of date relative to what's in 
Michael's patch.  So we'd either need a patch specific to the version in 
GCC right now or we'd need to update libtool.m4 then apply Michael's patch.

>
> I think that the problem for static linking needs to be addressed by collect2.
Could be -- I just don't have enough background to know either way.

jeff