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: Jeff Law <law at redhat dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>, Michael Haubenwallner <michael dot haubenwallner at ssi-schaefer dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 29 Mar 2017 13:50:56 -0600
- Subject: Re: [PATCH] Real fix for AIX exception handling
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A6086C03BD62
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A6086C03BD62
- References: <CAGWvny=1fOVUuomJ8BqTKsCO3E__mOHJZ+=3F9OWjVpTWZDzuA@mail.gmail.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