Re: GCC-3.0.1 can't compile Glibc-2.2.4

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

   Date: Mon, 1 Oct 2001 10:28:32 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   One more thing, when new DWARF-2 opcodes are added to libgcc, does
   anyone know what will happen to the interface of libgcc?

That really is something to ask on the GCC mailing list.  I'm under
the impression that the intention of the GCC developers is that
nothing will happen to them.

   Certainly, the binaries compiled with new gcc won't be compatible
   with the older libgcc_s.so.1. Something has to be done to
   libgcc_s.so.1 so that we will get a run-time error when it
   happens.

With the current unwinder, the binary will just abort() when an
exception is thrown.  Aborting seems a sane thing to do, since it's
not easy to distinguish this condition from random clobberation of
data in the program.

   There are 2 ways to detect this condition:

   1. Detect it as early as possible, when the incompatible binary is
   loaded into memory.

This isn't easy to do.  One must check whether the unwinder (provided
by libgcc_s.so.1) is compatible with the frame info in the modules
that make up the application.  Checking this in the frame registration
functions doesn't help since the frame registration functions are
seperate from the unwinder.  They might come from libc.so.  At best
you can provide a sense of false security.  That's what Richard
Henderson objected to, and I think rightly so.

You could try to detect any problems when the unwinder is loaded into
memory, but that would only be able to check frame info that has
already been registered at that stage.

So that only leaves us with:

   2. Detect it when the exception is thrown.

That's what the current code does (although instead of calling abort()
it might print a friendly message).

   If gcc does do #1, which I think is the right thing to do, does anyone
   know how it will impact dlopening libgcc_s.so.1? To me, there are so
   few benefits and so many unanswered questions, I don't think we should
   do dlopening libgcc_s.so.1 at all.

I don't see how we can reliably implement #1.  If we don't dlopen
libgcc_s.so.1 we might consider the unwinder and frame registration
functions coupled for legacy C++ code, and do the checking you
suggest, but libgcc_s.so.1 still enters the picture for new C++ code.
Adding the checks that you suggest will not only make it impossible to
compile glibc with future versions of GCC, but also make it impossible
to simply use glibc with future versions of GCC.

   BTW, one way to implement #1 for gcc is to update the version of those
   affected functions from GCC_3.0 to GCC_3.1, when the incompatible
   changes are made, and make the GCC_3.0 version of those functions
   invisible to ld. If gcc does that, we can check it in the glibc
   configure to verify if gcc is compatible with glibc. I can write a
   patch for that.

And what are in your view those affected functions?

I repeat once more that coupling glibc to a particular version of GCC
is something we should try to avoid.

Mark