Regression tester v. runtime libraries

Regression tester v. runtime libraries

[Joseph S. Myers]

Does the automated regression tester check for regressions in the
libstdc++-v3 and libjava testsuites?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Regression tester v. runtime libraries

[Phil Edwards]

On Thu, Nov 29, 2001 at 12:44:09PM +0000, Joseph S. Myers wrote:
> Does the automated regression tester check for regressions in the
> libstdc++-v3 and libjava testsuites?

I know libstdc++-v3 gets checked, or at least it used to.

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Regression tester v. runtime libraries

[Richard Henderson]

On Thu, Nov 29, 2001 at 12:44:09PM +0000, Joseph S. Myers wrote:
> Does the automated regression tester check for regressions in the
> libstdc++-v3 and libjava testsuites?

Yes.


r~

Re: Regression tester v. runtime libraries

[Geoff Keating]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> Does the automated regression tester check for regressions in the
> libstdc++-v3 and libjava testsuites?

In theory yes.

However,

- 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

- libjava never did get switched on, partly because it doesn't work on
  powerpc-eabisim, so it would only affect the x86 native, which makes
  it hard for others to fix any problems the regression tester finds.
  Maybe I should revisit this.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Regression tester v. runtime libraries

[Joseph S. Myers]

Does the automated regression tester check for regressions in the
libstdc++-v3 and libjava testsuites?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Regression tester v. runtime libraries

[Phil Edwards]

On Thu, Nov 29, 2001 at 12:44:09PM +0000, Joseph S. Myers wrote:
> Does the automated regression tester check for regressions in the
> libstdc++-v3 and libjava testsuites?

I know libstdc++-v3 gets checked, or at least it used to.

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Regression tester v. runtime libraries

[Richard Henderson]

On Thu, Nov 29, 2001 at 12:44:09PM +0000, Joseph S. Myers wrote:
> Does the automated regression tester check for regressions in the
> libstdc++-v3 and libjava testsuites?

Yes.


r~

Re: Regression tester v. runtime libraries

[Geoff Keating]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> Does the automated regression tester check for regressions in the
> libstdc++-v3 and libjava testsuites?

In theory yes.

However,

- 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

- libjava never did get switched on, partly because it doesn't work on
  powerpc-eabisim, so it would only affect the x86 native, which makes
  it hard for others to fix any problems the regression tester finds.
  Maybe I should revisit this.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: Regression tester v. runtime libraries

[Hans-Peter Nilsson]

On 30 Nov 2001, Geoff Keating wrote:
> "Joseph S. Myers" <jsm28@cam.ac.uk> writes:
>
> > Does the automated regression tester check for regressions in the
> > libstdc++-v3 and libjava testsuites?
>
> In theory yes.
>
> However,
>
> - 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.)

brgds, H-P

Re: Regression tester v. runtime libraries

[Geoff Keating]

> Date: Sun, 16 Dec 2001 00:02:58 -0500 (EST)
> From: Hans-Peter Nilsson <hp@bitrange.com>
> cc: "Joseph S. Myers" <jsm28@cam.ac.uk>, <gcc@gcc.gnu.org>
> 
> On 30 Nov 2001, Geoff Keating wrote:
> > "Joseph S. Myers" <jsm28@cam.ac.uk> writes:
> >
> > > Does the automated regression tester check for regressions in the
> > > libstdc++-v3 and libjava testsuites?
> >
> > In theory yes.
> >
> > However,
> >
> > - 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.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: Regression tester v. runtime libraries

[Hans-Peter Nilsson]

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.