Re: gcc 3.x test matrix

[Mark Kettenis <kettenis at science dot uva dot nl>]

"H . J . Lu" <hjl@lucon.org> writes:

> Here is something I come up with.

I don't think it's our job to check whether the GCC folks are
correctly maintaining maintaining binary compatibility.  It should be
safe to restrict ourselves to GCC 2.95.4 (with the "standard" patches)
and GCC 3.0.1.

What we should do is check whether Jakub's new implementations of
__frame_state_for and _Unwind_Find_FDE do their job correctly.

I posted a basic test for __frame_state_for to libc-hacker.  This test
checks whether __frame_state_for can find the frame info for several
functions in glibc that are compiled with -fexceptions, for example
qsort.  This test should be run on systems with and without a shared
libgcc.so.1 (from GCC 3.0.1), both for a glibc compiled with GCC
2.95.4 and GCC 3.0.1.

This test doesn't check whether the information returned by
__frame_state_for is correct.  The best way to do this, is probably by
writing a C++ test program that actually throws an exception through
functions like qsort.  This C++ program should be compiled with GCC
2.95.4 and we should use the same test-matrix as for the test above.

In order to check whether _Unwind_Find_FDE does work correctly we need
a few more tests.  The C++ program mentioned above is usable.  We
should also have a program that throws exceptions from and through a
C++ DSO, and we should have a C program that dynamically loads a C++
DSO, and throws an exception from it.  These programs and DSO's should
be compiled with GCC 3.0.1, and we should run the test both for glibc
compiled with GCC 2.95.4 and GCC 3.0.1.

I'll try to write the remaining test programs.  Unfortunately, it's
not likely that I'll be able to do any of the actual testing, since my
old Pentium MMX is far too slow and doesn't have enough disk space.
I'm happy to coordinate the testing though.

Mark