Re: GCC 3.0 Release Criteria

[Geoff Keating <geoffk at cygnus dot com>]

Chip Salzenberg <chip@valinux.com> writes:

> According to Geoff Keating:
> > Chip:
> > > We had problems on elf-i386 until I introduced a patch that separated
> > > the exception unwinding format from the number of hard registers.  But
> > > it's just a happy coincidence that a patch was possible.
> > 
> > I don't believe that this new scheme will allow people to change the
> > libgcc interface at will, any more than the old one would.  You would
> > have had a very similar problem.
> 
> I concur.  My point, however, is that if the interface did actually
> _have_ to change, then wouldn't that require a new soname?  Or is
> symbol versioning sophisticated enough to represent functions that are
> simply no longer available?

That's not what symbol versioning is for.  The idea is that you can
_always_ substitute a new libgcc.so for an old one, and all the old
applications will still work.

You don't just add a complete new implementation, though; you must make
the old and new implementations work together.  For instance, when glibc
changed the FILE data structure, the developers had to write a whole bunch
of compatibility code so that, for instance, if an old shared object called
the old fopen() and handed the result to a new application which called
the new fprintf(), it would still work; and so that if an old shared object
called fprintf(stdout, foo) and a new application then did the same thing,
that the buffering would work correctly.

For most libgcc functions, this is irrelevant, because it's hard to
imagine any circumstances under which, for instance, _ashldi3 would
become unimplementable.
-- 
- Geoffrey Keating <geoffk@cygnus.com>