From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10316 invoked by alias); 23 Dec 2001 03:07:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 10295 invoked from network); 23 Dec 2001 03:07:35 -0000 Received: from unknown (HELO dair.pair.com) (209.68.1.49) by sources.redhat.com with SMTP; 23 Dec 2001 03:07:35 -0000 Received: (qmail 80250 invoked by uid 20157); 23 Dec 2001 03:07:34 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 Dec 2001 03:07:34 -0000 Date: Sat, 22 Dec 2001 20:20:00 -0000 From: Hans-Peter Nilsson X-Sender: To: Geoff Keating cc: , Subject: Re: Regression tester v. runtime libraries In-Reply-To: <200112222113.NAA03925@geoffk.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-12/txt/msg01243.txt.bz2 On Sat, 22 Dec 2001, Geoff Keating wrote: > > Date: Sun, 16 Dec 2001 00:02:58 -0500 (EST) > > From: Hans-Peter Nilsson > > On 30 Nov 2001, Geoff Keating wrote: > > > - libstdc++-v3 got switched off because of a bug in linking C++ > > > objects compiled with different optimisation levels that would cause > > > FAILs to appear and disappear at random; and > > > > Is that the gcc <-> binutils mismatch with relocs against > > symbols in discarded linkonce sections that we discussed on the > > binutils list some time ago? (That description certainly > > matches what I saw then.) > > Yes, it's the bug where EH information ends up in the executable for > linkonce functions that were deleted. Not a precise enough description for my hair-splitting. Fixable by s/the executable/some exception helper table generated at run-time/ though. I think I should summarize my recollection: the EH information was (is?) emitted to one and the same section, .eh_frame for all code, while the code itself would as usual be split into function-named linkonce-sections for template instantiations and similar. The problem was that binutils stopped emitting zero for relocs to the discarded linkonce code sections (the duplicate template instantiations) while GCC still expected zero emitted there, which it would use to filter out EH records for the discarded sections. IIRC, the relocated data, in place of the zero, points to the remaining section, so it looks valid. This mismatch started with binutils 2.11. H.J. has imported the fix into his binutils releases AFAIK. It was concluded that emitting zero for linkonce-discarded sections wasn't really right. Instead, a link error was TRT, but zero would be continued to be emitted for compatibility with older GCC for a limited period, until releases of gcc with a new scheme are abundant, where the EH info for a function is discarded together with the code. I haven't checked, but I hope this new layout scheme is in 3.1. Hope to do more than hope, soon I hope. The mismatch will result in incorrect frame information when unwinding the stack. It will be seen as uncaught_exception (usually leading on to abort) being called IIRC. This will happen only if the library and the program are compiled with different optimization options or different releases of GCC (so there are different stack frame information for the included and the excluded linkonce sections), and if a helper table that is generated at exception-time has the "excluded" EH info entries at an unfortunate place. To wit, it'll break if your program throws an exception and you're (deterministically) unlucky with the EH info layout. I don't remember if there are additional requirements; it may be restricted to only exceptions passing functions that are part of a template instantiation. The scenario can be visualized as using the result of bsearching a sorted table required to have unique keys, but in fact having duplicate keys for some entries with bogus data. Point being, IMHO the regression tester should test libstdc++-v3 too now. If the EH info layout in GCC isn't "fixed", it should use binutils CVS (or a release with the zero-emitting fix) for both the powerpc-sim and native tests. brgds, H-P PS. Happy holidays.