Re: A completely different approach to EH runtime

[Joe Buck <jbuck at synopsys dot COM>]

I wrote:
> > OK, glibc people, consider yourselves asked.  However, I *also* would like
> > to hear from maintainers of the C library on BSD systems as to what
> > problems *they* forsee (since they would also have a shared libgcc to deal
> > with).

David O'Brien writes:
> I have zero intention of supporting a shared libgcc in stock FreeBSD,
> even with GCC 3.0.
> (Well, not entirely true.  I may very well, but the shared lib version
> numbering will be *very* controlled to not cause problems with upgrades,
> backwards compatibility, etc..)
> 
> While I certainly do not have such control over stock FSF/GNU GCC, I
> would like to say I'm still leery of a shared libgcc being used in a
> stock by-hand stock FSF sources GCC install.  (I feel the same about
> libstdc++)

I understand and respect your caution, but I'd like to answer it by
establishing policies that would enable the BSD and GNU/Linux distributors
to use a shared libgcc with confidence.  The polcies would require the
very controlled handling of version numbering and backward compatibility
you refer to.  If we don't convince you that we did it right, then of
course you won't use the feature.  And I'd rather have the discussion
in advance so that we don't have people solving the problem in different
ways, thus reducing portability.

Without a shared libgcc, we have difficulties with handling exceptions in
shared libraries.  Some have argued for making only the exception-handling
component shared and leaving, say, implementations of multiplication for
"long long" static.  However, for processor families it can be a big win
to make these calls shared exactly so that we can generate code that runs
on, say, a Sparc v7 or a 486 but gets speedups on an Ultrasparc or Pentium
II (e.g. on Solaris the call to the shared .div function works on
processors that lack integer divide or those that have it, and those that
have it have a .div implementation that is much faster.  So I don't see
much gain in splitting libgcc into two and sharing only the exceptions
part.