Re: c++/9265: exception handling faulty wenn linking PIC objects to non PIC ones

[Robert Schiele <rschiele@uni-mannheim.de>]

The following reply was made to PR c++/9265; it has been noted by GNATS.

From: Robert Schiele <rschiele@uni-mannheim.de>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: cc@pi3.informatik.uni-mannheim.de, gcc-bugs@gcc.gnu.org,
	gcc-gnats@gcc.gnu.org, Andreas Jaeger <aj@suse.de>,
	Volker Reichelt <reichelt@igpm.rwth-aachen.de>,
	Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>
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--