Re: gcc 3.x test matrix

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

   Date: Thu, 6 Sep 2001 14:38:28 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   On Thu, Sep 06, 2001 at 11:04:45PM +0200, Mark Kettenis wrote:
   >    Date: Wed, 5 Sep 2001 23:00:14 -0700
   >    From: "H . J . Lu" <hjl@lucon.org>
   > 
   >    I disagreee. The whole idea of dlopening libgcc.so.1 is for future
   >    changes in gcc. If we have no ideas about what the impacts of those
   >    changes are, how do we know this scheme will work? There are many
   >    ways for gcc to provide the binary compatibility. I don't think it
   >    will work right if gcc and glibc don't work together from the very
   >    beginning.
   > 
   > The very beginning is GCC 3.0.1 (and apparently GCC 3.0.2 for
   > PowerPC).  IMHO, checking whether new versions of GCC will work right
   > with glibc should be part of the GCC release procedures.

   If glibc chooses a scheme which will never work with the future gcc
   changes, how can it work? libgcc_s.so.2?

Now where did I put my crystal ball... ;-)

Seriously, we cannot test whether we've chosen a scheme that will work
with a future version of GCC.  We have designed it with the goal that
it will work with future versions of GCC, and if we've done our job
right it just will.  No guarantees though.

   > That said, it doesn't hurt to somehow test mainline GCC, and I'll be
   > happy to include results in my test reports.  I just don't want to
   > increase the number of permutations that we need to test without a
   > good reason.  If glibc doesn't work with GCC 3.x, it's GCC 3.x that
   > needs to be fixed, not glibc.

   I never said it would be easy. However, we can ask the gcc developers
   for the possible future changes in the libgcc_s.so ABI and make a new
   gcc based on gcc 3.0.x to try them out. We don't even have to make any
   real code changes, only the ABI changes.

Changes to the frame info registration blackbox ABI
(__register_frame_info*, __deregister_frame_info* and
_Unwind_Find_FDE) will require changes in glibc.  Richard has
indicated that it's not very likely that such ABI changes are needed
in the forseeable future.  There is no point in "testing" such
changes.

Other changes to the libgcc_s.so.1 ABI shouldn't affect glibc at all.

Of course I'm assuming here that they won't actually *break* the ABI,
but I trust the GCC folks not to do that.

Mark