On Thu, Mar 30, 2017 at 4:11 AM, Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com> wrote: > On 03/29/2017 10:21 PM, David Edelsohn wrote: >> 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. > > When statically linked, shouldn't collect2 add libstdc++'s EH frames to > the main executable's registration table again? > Or is libstdc++'s constructor called instead? > >> 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. > > Wild guess: > When (and how) did you disable runtime linking (-G) for libstdc++? > Maybe there's a side effect related to -bsymbolic when statically linking > a shared object.
Yes, two hypotheses are: 1) The removal of -G AIX linker option that allowed runtime overriding of libstdc++ symbols and somehow allowed merging of symbols when linking statically. 2) Change in order of initialization from AIX default breadth first to force SVR4-like depth first. > >> Note that AIX does not install a separate libstdc++ static archive and >> instead statically links against the shared object. > > Note that libtool's --with-aix-soname=svr4 would behave different here... > >> 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. > > Next wild guess: When libstdc++'s EH frames are registered calling > libstdc++'s constructor even when statically linked rather than being > added to main executable's table, both registered EH tables may overlap > each other - where attached patch might help... Thanks, David