On Wed, Mar 29, 2017 at 3:50 PM, Jeff Law <l...@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
