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

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

"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.

To clarify what Jakub already said about why we need to dlopen
libgcc_s.so.1: Future versions of GCC might emit new DWARF2 opcodes.
The copy of unwind-dw2.c that Jakub's patch adds to glibc, will not be
able to handle these.  If one now recompiles glibc with this future
version of GCC throwing exceptions through lsearch(), qsort(), etc. won't
work anymore.  So if we don't dlopen libgcc_s.so.1 we will need to
synchronize glibc and GCC releases.  That's undesirable.

A similar situation exists for other shared libraries that contain
code compiled with -fexceptions that are used by C++ code generated by
GCC 2.  I'm not aware of any, but with the dlopen strategy people at
least have the possibility to fix the problems by upgrading
libgcc_s.so.1.

As for the status of Jakub's patch.  The way Jakub changed
elf/soinit.c:__libc_global_ctors() is wrong.  This code should simply
call __register_frame_info_bases().  There's no point in handling
where libstdc++ from GCC 2 comes earlier in search scope.  If it does,
things are broken anyway since __frame_state_for in libstdc++ will be
used and that one doesn't handle the frame info generated by GCC 3
anyway.  In addition, the code relies on the internals of the current
unwind-dw2-fde.c code.  This will break if the those internals are
changed in a future version of GCC and libgcc_s.so.1 comes earlier in
the search scope than glibc.

Aport from the problem indicated above, there's no point in installing
Jakub's patch as long as libstdc++ still contains a copy of
__frame_state_for.  A remedy was briefly discussed on libc-alpha,
see:

  http://sources.redhat.com/ml/libc-alpha/2001-09/msg00017.html

and subsequent messages.  I'm not sure concensus has been reached on
this issue.  I didn't notice that the necessary changes have been made
to GCC's gcc-2_95-branch.

Only Andreas Jeager has taken the trouble to run the tests I posted.
His results indicate that x86 will be fine once the libstdc++ issue
has been dealt with, and that powerpc will work fine with the upcoming
GCC 3.0.2.  Other platforms are basically untested AFAIK.

The bottomline is, that there is still some work to do.  Somebody
should get the necessary patches for GCC 2.95.x together and get them
checked in.  People should also run the tests I posted on as many
platforms as possible.  I'm not going to be any of those people.

If nobody steps up to do the hard work, I think Ulrich should simply
branch and install Jakub's patch on the trunk.  We can always backport
the changes if we feel the need.

Mark