This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Real fix for AIX exception handling
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Michael Haubenwallner <michael dot haubenwallner at ssi-schaefer dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 27 Mar 2017 11:41:28 -0400
- Subject: Re: [PATCH] Real fix for AIX exception handling
- Authentication-results: sourceware.org; auth=none
> 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 when
> 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. And there seems to be different behavior for GCC 4.8 and GCC
4.9.
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.
I think that the problem for static linking needs to be addressed by collect2.
Thanks, David
P.S. Please explicitly copy me on AIX patches.