From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24192 invoked by alias); 13 Jan 2003 23:36:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 24178 invoked by uid 71); 13 Jan 2003 23:36:01 -0000 Date: Mon, 13 Jan 2003 23:36:00 -0000 Message-ID: <20030113233601.24177.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Robert Schiele Subject: Re: c++/9265: exception handling faulty wenn linking PIC objects to non PIC ones Reply-To: Robert Schiele X-SW-Source: 2003-01/txt/msg00843.txt.bz2 List-Id: The following reply was made to PR c++/9265; it has been noted by GNATS. From: Robert Schiele To: Wolfgang Bangerth Cc: cc@pi3.informatik.uni-mannheim.de, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, Andreas Jaeger , Volker Reichelt , Christian Ehrhardt Subject: Re: c++/9265: exception handling faulty wenn linking PIC objects to non PIC ones Date: Tue, 14 Jan 2003 00:29:51 +0100 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 13, 2003 at 04:42:07PM -0600, Wolfgang Bangerth wrote: >=20 > > > I have mainline snapshots from the last two years for about every two= =20 > > > weeks, and none of them shows the behavior you see. > >=20 > > You still didn't answer my question, which binutils you use. Might be > > this information is of some use to understand the problem. >=20 > I'm sorry. For the RedHat machine with the snapshot collection, it's=20 > 2.11.90.0.8, for the SuSE machine it's 2.11.92.0.10. Hmm, SuSE 8.1 has 2.12.90.0.12. Is someone else with 2.12.x.x.x here to test this? > > > What do we do with this report? > >=20 > > I hope you do not ignore it. My colleague and I have invested some > > time to track this down to such a simple test case. (The real world > > test case were megabytes of code.) >=20 > I have no intention to _ignore_ the report, otherwise I would have closed= =20 > it after not being able to reproduce it. On the other hand, we rely on=20 > being able to reproduce a problem to fix it, right? Yes you are right. Sorry, might be I was a bit too harsh here. Hope you don't mind. > Volker, Christian, can one of you try to check this report on your=20 > systems? I think I have to pull out of this since I can't contribute=20 > anything any more... Well, I did some more testing and found the following: If I do compile and link with gcc 3.2.1, the resulting application is faulty. Linking is done by: /opt/Pkg/Linux/i686/gcc321/lib/gcc-lib/i486-suse-linux/3.2.1/collect2 --eh-= frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /u= sr/lib/crti.o /opt/Pkg/Linux/i686/gcc321/lib/gcc-lib/i486-suse-linux/3.2.1/= crtbegin.o -L/opt/Pkg/Linux/i686/gcc321/lib/gcc-lib/i486-suse-linux/3.2.1 -= L/opt/Pkg/Linux/i686/gcc321/lib/gcc-lib/i486-suse-linux/3.2.1/../../.. pic.= o nopic.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /opt/Pkg/Linux/i686/= gcc321/lib/gcc-lib/i486-suse-linux/3.2.1/crtend.o /usr/lib/crtn.o If I replace _only_ crtbegin.o with the one from gcc 3.2 release, the resulting application works perfectly sane. So the bug must be somewhere in crtstuff. Well crtstuff.c itself was not changed, so this must be something in a file included from there. Or the reason is that I have built the 3.2 release with binutils 2.11.x.x.x where I have built the other compilers with 2.12.x.x.x. Wolfgang could you send me the crtbegin.o files from the compilers that you tried? Robert --=20 Robert Schiele Tel.: +49-621-181-2517 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iQEVAwUBPiNL7sQAnns5HcHpAQFzwAgA0afd+Q4xtOH4nQ4ezjDmlEimwM7UWTbC d8yHpKkhQxbdeDJe9FfTt72pt79JZ+JzbB0x9mxRXpJRMnPofB07FbV5T9BfmAsF yovdJrkFD5sCVkpCk3y6EU2/V4d78kiZGJa6v47t9/mEUKRP0q9I+7SN9JFx2Vem RMPEIICY/p8EgElYUn9FuctwUzvt8pPxYzn4SWC/07JD39lFnARjytP2CLS93jLV +OoLatLvxpXtsutic4nS6kJGILJ60xgPloOqKHwInNhuNaJ9izwABrHfmJysIySW PcJLUD2fPmqc6iOO44JW8cjZwd2FQwAH90JbwX+AKsSwC6eYBvpCLA== =PGEQ -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU--