Versioning problem with __register_frame

["Martin Schwidefsky" <schwidefsky at de dot ibm dot com>]

Hi,
we have been hit by an ugly problem with the new glibc-2.2.5 on s390x.
Its boils down to a combination of two problems, one in binutils and
one in glibc. The problem in binutils is that function calls to
undefined weak external references gets "optimized" to calls to 0. The
glibc problem for s390x (and some other architectures as far as I can
see) are missing versions for some symbols, for s390x and glibc 2.2.4
these are the symbols __register_frame, __register_frame_table,
__deregister_frame, __register_frame_info, __deregister_frame_info,
__frame_state_for and __register_frame_info_table. Because there is
no version for these symbols they are local to the libc. Now due to
the binutils problem calls to e.g. __register_frame_info are "optimized"
to 0. This is done in crtbeginS.o which gets linked to every executable
in the system. Since the code in crtbeginS.o tests __register_frame_info
against NULL before calling it, this hasn't caused a problem so far.
With glibc 2.2.5 the elf/Versions file exports __register_frame_info.
Now __register_frame_info is not NULL and the call to 0 crashes every
executable linked with the broken binutils against an older glibc.

The solution is to fix the "optimization" in the binutils, relink every
executable (autsch), add correct versions for the missing symbols to
glibc and install the fixed glibc. The binutils fix is done, the relink
is our problem but I have a question about the correct way to get
the missing versions into glibc.
__register_frame_info and __deregister_frame_info in glibc-2.2.5 are
versioned in the elf/Versions file as GLIBC_2.0 symbols. Does this mean
that we have to make them GLIBC_2.0 versioned symbols although the
earliest symbol set for s390x is GLIBC_2.2 ?

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com