Re: Shared library annoyance with gcc-3_0-branch

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

   From: Geoff Keating <geoffk@geoffk.org> 
   Date: Mon, 19 Feb 2001 00:07:29 -0800 

   > Date: Sun, 18 Feb 2001 20:23:35 -0800
   > From: "H . J . Lu" <hjl@valinux.com>

   > How do I know it will be the case? Is there a "libgccabi.h" which
   > defines functions and data strucures exported by libgcc? I know
   > the interface of libgcc was changed at least once in the last year.
   > You got away with it because
   > 
   > 1. There was no "libgccabi.h" to even check it.
   > 2. libgcc was not shared.

I don't see why having a (semi-)public header file would be of any
significant help with maintaining a backwards compatible ABI.  It
wouldn't suffice as proper documentation of the libgcc ABI.

   It has always been the case that the libgcc ABI cannot change in a
   backwards-incompatible way, as this would mean that, for instance, .a
   libraries built under an earlier version of gcc would fail to link or
   fail to work under a later version.  I really hope the ABI didn't
   change, because if it did it will break something.

I remember some problems with the ia64 exception handler frame
registration stuff:

   http://sources.redhat.com/ml/libc-hacker/2000-07/msg00103.html

However that's in a not yet officially released GCC version, so
breaking the ABI there was perfectly all right (although annoying for
the developers on that platform, as is apparent from HJ's continued
beating on this subject).

There also was a problem when a new dwarf opcode (in this case
DW_CFA_def_cfa_expression) was added, see your own message on
libc-alpha:

   http://sources.redhat.com/ml/libc-alpha/2000-07/msg00013.html

I don't know how this was resolved, or even if it was resolved.  But
this issue should be properly documented by someone knowledgable.

Mark