Re: __register_frame_info & shared library compatibility

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

   Date: Wed, 14 Apr 1999 15:09:36 -0600
   From: Jeffrey A Law <law@upchuck.cygnus.com>

     In message <199904141258.OAA22629@landau.wins.uva.nl>you write:
     >    If you can find a solution that works in both worlds, then great.
     >    But I do not believe one exists.  And in the absence of a perfect
     >    solution we must continue be compatible with our own releases over
     >    compatibility with gcc-2.7.
     > 
     > What about my suggestion to use weak references to
     > __register_frame_info and __deregister_frame_info in crtbegin.o and
     > normal (non-weak) references in crtbeginS.o?

   I must have glossed over it.  If you've got it handy, can you
   resend (or I'll grope around the archives for it).

I don't have a patch at the moment.  It is just an idea that I wanted
to check with a few people before checking out how to implement it in
a clean way.

The idea is to use the fact that for a number of ELF targets there are
two crtbegin files.  crtbegin.o is used for normal programs and
crtbeginS.o is copiled with -fPIC for use in shared libraries.  The
idea is that as long as we keep the normal (non-weak) references to
__register_frame_info and __deregister_frame_info in crtbeginS.o the
same shared libraries end up with __register_frame_info and
__deregister_frame_info as with egcs-1.1.1.  But I think we are free
to make the references in crtbegin.o weak.  This would mean that
programs that don't explicitly use exception handling would run fine
if these symbols are not available.

What I'd like to know is if it is acceptable to make crtbegin.o and
crtbeginS.o different in this respect, and if you can shoot any holes
in my little theory.

Note that this solution isn't perfect.  Not all targets seem to have
seperate crtbegin.o and crtbeginS.o files.  And it is still not
possible to arbitrarily exchange shared libraries between systems with
an egcs compiled glibc 2.0 and an gcc 2.7 compiled glibc 2.0.  But I
think it is better than the egcs 1.1.1 situation.

Mark