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

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

   Date: Tue, 25 Sep 2001 10:21:11 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   On Mon, Sep 24, 2001 at 11:34:04PM +0200, Mark Kettenis wrote:
   > "H . J . Lu" <hjl@lucon.org> writes:
   > 
   > > Ok, I will buy that. But it was not clear to me what dlopening
   > > libgcc_s.so.1 could do and wouldn't do. Assuming what you said is true,
   > > I have some questions on its effectiveness. When it happens, your
   > > scheme will only work when libgcc_s.so.1 is also upgraded to the
   > > compatible one which is used to compile the C++ applications. I'd like
   > > to ask
   > > 
   > > 1. How often is it true?
   > > 2. If libgcc_s.so.1 is upgraded and we don't do dlopening libgcc_s.so.1
   > > in glibc, how often won't the functions in libgcc_s.so.1 be used?
   > > 
   > > I have an impression that for most cases, the functions in libgcc_s.so.1
   > > will be used anyway regardless if you do dlopening libgcc_s.so.1 or not.
   > > 
   > 
   > Dlopening libgcc_s.so.1 only happens in a response to a call to
   > __frame_state_for(), that is, for C++ code generated by GCC 2.  In
   > general libgcc_s.so.1 will not be already loaded in that case.
   > 

   I don't think it is very useful unless I missed something very obvious.

Providing support for future versions of GCC isn't useful?

   May I ask under what condition the C++ code generated by gcc 2 will
   call __frame_state_for in gcc 3?

What do you mean with "call __frame_state_for in gcc 3"?

   It seems to me that it will only happen in libc.so compiled by gcc 3.

What *exactly* will "only happen in libc.so compiled by gcc 3".

   Why can't we put a check in glibc such that only the compatible
   versions of gcc 3 can be used to compile glibc?

Define "compatible versions of GCC 3".  Assuming that you mean a
version of GCC 3 that doesn't emit DWARF2 opcodes that aren't handled
by the unwinder in libc.so: Adding the checks is possible (and in fact
I already posted a test that does these checks), but running them only
makes sense after you've built glibc.

   That is __frame_state_for in glibc should be compatible with the
   gcc 3 used to build it.

That means that we'll have to upgrade the code in glibc every time GCC
is changed to emit new DWARF2 opcodes.  Several people have said
that's undesirable.

   Is that too much to ask?

I don't know.  Why do you think dlopening libgcc_s.so.1 is not a good
idea?  Is it just that you fee that it needlessly adds a little
complexity, or do you have a possible scenario in mind where it will
fail?

Mark