From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28879 invoked by alias); 17 Feb 2008 16:45:48 -0000 Received: (qmail 28766 invoked by alias); 17 Feb 2008 16:45:05 -0000 Date: Sun, 17 Feb 2008 16:45:00 -0000 Message-ID: <20080217164505.28765.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/35222] [4.3 Regression] EH output contains procedure label without P' selector In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dave at hiauly1 dot hia dot nrc dot ca" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-02/txt/msg01908.txt.bz2 ------- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-17 16:45 ------- Subject: Re: [4.3 Regression] EH output contains procedure label without P' selector > Does this also fail for hppa2.0w-hp-hpux11.11 which would be a secondary target > unlike hppa1.1-hp-hpux10.20 which is neither primary nor secondary? It doesn't affect hppa2.0w-hp-hpux11.11. There is a difference in the methods used to achieve one-only support. hppa2.0w-hp-hpux11.11 uses secondary definitions and hppa1.1-hp-hpux10.20 COMDAT subspaces. My current understanding of the problem is that the error occurs when a COMDAT subspace is not used. This leads to the situation where the local symbols referenced in the EH data no longer are satisfied. It's still a puzzle as to why this didn't appear before. I'm testing a one line fix to the encoding to add the P' descriptor. This isn't exactly obvious as normally when the P' descriptor is used the pointer ends up pointing to a function descriptor rather than to the label in the code. However, in this case, the labels are local and not exported. I think the linker is smart enough in this case to create a direct pointer. I'm hoping in the COMDAT case that a function descriptor will be created and there won't be problems with unresolved symbols. If the above doesn't work, I have a small change to config.gcc to force sjlj exception suport. I've been trying to test the above change but hit the libstdc++ breakage on head. I have had one successful build with the change on hppa64-hp-hpux11.11 using 4.2.4. libstdc++ builds with the change on hppa2.0w-hp-hpux11.11 on head. Unfortunately, my hppa1.1-hp-hpux10.20 system is somewhat slow and I'm just restarting the build there. I'm also testing with 11.00. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35222