From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34945 invoked by alias); 29 Mar 2017 19:51:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 34929 invoked by uid 89); 29 Mar 2017 19:50:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*M:97fa, wondering X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Mar 2017 19:50:58 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A6086C03BD62; Wed, 29 Mar 2017 19:50:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A6086C03BD62 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@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A6086C03BD62 Received: from localhost.localdomain (ovpn-116-218.phx2.redhat.com [10.3.116.218]) by smtp.corp.redhat.com (Postfix) with ESMTP id 41DA718996; Wed, 29 Mar 2017 19:50:57 +0000 (UTC) Subject: Re: [PATCH] Real fix for AIX exception handling To: David Edelsohn , Michael Haubenwallner References: Cc: GCC Patches From: Jeff Law Message-ID: Date: Wed, 29 Mar 2017 20:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg01491.txt.bz2 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