Re: Regression tester v. runtime libraries

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Sat, 22 Dec 2001, Geoff Keating wrote:
> > Date: Sun, 16 Dec 2001 00:02:58 -0500 (EST)
> > From: Hans-Peter Nilsson <hp@bitrange.com>
> > 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.