Re: __register_frame_info & shared library compatibility

[Jeffrey A Law <law at upchuck dot cygnus dot com>]

  In message <199904071214.OAA13954@landau.wins.uva.nl>you write:
  > I think that you mean "__register_frame" instead of
  > "__register_frame_info".
Yea.  Minor details :-)


  >    Against our recommendations, the interface was removed from gcc2.8.
  > 
  > The "__register_frame" interface was never included in any official
  > FSF release of gcc before 2.8.
I'm well aware of that.  It had been the interface that had been in the gcc
tree for nearly 2 years though.  It was changed about 2 weeks before gcc-2.8
went out the door and just after egcs-1.0 had been released.


  > Back then, egcs was still
  > "experimental" which was probably the reason why Kenner didn't want to
  > include the (broken) "__register_frame" interface that was part of
  > egcs 1.0 in gcc 2.8.
There were other reasons.  Some technical, but mostly political.


  > However, compatibility for the old "__register_frame" was included in
  > gcc 2.8.1.  This has not been noticed by a lot of people since,
  > where the "__register_frame_info" and "__register_frame" functions are
  > part of the same object module in egcs's libgcc.a, they are in different
  > modules in gcc's libgcc.a. This was exactly why 
I didn't know they'd included it in gcc-2.8.1.   Good.  However keeping them
in different modules is still not necessarily right, particularly when one
considers shared libraries and dynamically loaded code.

  > However, this issue is irrelevant for the current
  > "__register_frame_info & shared library compatibility" discussion.
  > The way "__register_frame_info" is referenced in 2.8 <= gcc <= 2.8.1
  > and 1.0.3 <= egcs <= 1.1.1 is in principle the same.  The problem is
  > indeed that egcs 1.1.2 now puts only a weak reference to
  > "__register_frame_info" in crtstuff.  This means that "du moment" one
  > recompiles a shared library that previously contained
  > "__register_frame_info" it probably does not anymore, and programs
  > linked with that library stop running.
Yup.  And I consider this a horrible breakage.  I trusted a couple of folks
with more experience in this area to guide the decision to include that
patch.  They made a mistake.  We need to rectify it.

  > Now, things get really complicated because of the egcs/Linux
  > ``releases''.  In an attempt to fix problems the author has messed
  > around with the way "__register_frame_info" is used in the varied
  > egcs-1.1.1/Linux ``releases''.  This might mean that some people that
  > use these versions will experience the same problems, but report that
  > they're using egcs-1.1.1 instead of egcs-1.1.2.  IMHO we have to
  > prevent that this happens again for egcs-1.1.2, and discourage the
  > author to release any "fixed" version of egcs-1.1.2.
Or fix this (and only this) problem and make egcs-1.1.3.

  > It is probably not a bad idea to revert the weak reference to
  > "__register_frame_info" patch in egcs-1.1.2.  It may result in larger
  > executables with glibc 2.0, but at least we get rid of the shared
  > library compatibility problem.  For glibc 2.1 things shouldn't matter
  > since "__register_frame_info" is exported from libc, which by default
  > every program and shared library is linked against.
jeff