From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26768 invoked by alias); 29 Mar 2017 21:51:36 -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 25649 invoked by uid 89); 29 Mar 2017 21:51:35 -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=Hx-languages-length:3000, essentially 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 21:51:33 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1FB4380F9E; Wed, 29 Mar 2017 21:51:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1FB4380F9E Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1FB4380F9E Received: from localhost.localdomain (ovpn-116-218.phx2.redhat.com [10.3.116.218]) by smtp.corp.redhat.com (Postfix) with ESMTP id DA57E60F8B; Wed, 29 Mar 2017 21:51:32 +0000 (UTC) Subject: Re: [PATCH] Real fix for AIX exception handling To: David Edelsohn References: <4ef6498d-dc73-f953-5987-2febb5b7dd3e@redhat.com> Cc: Michael Haubenwallner , GCC Patches From: Jeff Law Message-ID: Date: Wed, 29 Mar 2017 22:29: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/msg01506.txt.bz2 On 03/29/2017 03:22 PM, David Edelsohn wrote: > On Wed, Mar 29, 2017 at 5:20 PM, Jeff Law wrote: >> On 03/29/2017 02:56 PM, David Edelsohn wrote: >>> >>> On Wed, Mar 29, 2017 at 4:48 PM, Jeff Law wrote: >>>> >>>> On 03/29/2017 02:21 PM, David Edelsohn wrote: >>>>> >>>>> >>>>> >>>>> 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. >>>> >>>> >>>> Hmm, the act of statically linking against the shared libstdc++ certainly >>>> adds a wrinkle here. >>>> >>>> It's been a *long* time since I had to think about this stuff for a >>>> non-ELF >>>> system. Please correct me if I goof anything up. >>>> >>>> Since we build a shared libstdc++, doesn't that set up a library ctor >>>> which >>>> should register the EH tables for the library as a whole? >>>> >>>> When we link against that library statically, we have to arrange to run >>>> the >>>> library's ctor from the main program's global ctors. Right? ie, it >>>> should >>>> be OK to have separate copies -- we just have to get them all registered >>>> properly? Right? >>> >>> >>> GCC has to get them all of the EH frames registered into one table, >>> otherwise libgcc walks the frames to find a catcher for an exception >>> and doesn't find the address of the program counter in the sorted >>> table because that range was recorded in the other table. >> >> Right. We have to register all the frame_infos into a single table. I was >> mostly focused on the registration mechanism. My recollection is that we'll >> create a library-wide ctor for libstdc++ which would register the >> frame_infos for the library and that ctor should be run by the main program. >> The main program will collect its own frame_infos and register them as well. > > Yes, collect2 essentially creates a constructor that it schedules at a > high priority to record the frames that it found during the scan. OK. So I'd first verify there is a constructor for the libstdc++ library as a whole via nm/objdump. Then I'd verify that library constructor shows up in the ctor list for the main executable -- not sure the best way to do that. jeff