Shared library annoyance with gcc-3_0-branch

[Linus Torvalds]

On Tue, 20 Feb 2001, Joe Buck wrote:
> 
> But we can't just move exception handling to a language-specific library,
> because we are attempting to support cross-language exception mechanisms
> (for example, C++ and Ada).

Oh, agreed. I certainly don't think it should be "language-specific".

Anything that uses exceptions should load it. Whether it be Ada, C++, or
anything else. But by separating out the exceptions from libgcc, at least
it might be possible to avoid this issue for system binaries etc that
really don't want to have anything to do with this.

(And note that "system binary" does not imply that gcc is necessarily a
"system compiler". You might have local people using gcc for local use,
and wanting to use the binaries generated at other sites..)

> > That way, even if no good solution that makes everybody happy is found, at
> > least we confine the problem case a bit..
> 
> Let's not give up on making everybody happy just yet.

I suspect that even if you can make everybody happy, the fact that
exception handling _is_ so different (and that various variations on this
discussion have come up several times), it would be a good idea to
separate exception handling out regardless of peoples general happiness-
level.

For example, issues like "__udivdi3" are purely a gcc calling convention
issue, and could be easily changed even on a per-object-file basis (or
even per-use basis) by just creating new versions of them and linking them
statically into the program. I maintain, for example, that it might make
tons of sense to at some point change the calling conventions for some of
these things, and gcc can easily do it by just also changing the name of
the helper function in libgcc proper - without having _any_ backwards
compatibility issues at all, ie you can freely mix old and new object
files and libraries, and nobody needs to worry.

The above is generally true of _everything_ in libgcc. 

Except for exception handling. Which _is_ different.

Exception handling is a "global" issue, not just from a loading/linking
standpoint, but also because you cannot mix and match different versions.
So there are quite fundamental reasons to consider the "core" of libgcc
(instruction libraries) separate from the exception handling.

Trust me, this thing will come up in another two years, when people come
up with better exception handling needed to handle some new language or
standard or whatever. And I suspect you'll be happier if you can see it as
_purely_ an exception handling issue.

(Or the other way around: you start adding new intrisics for streaming
data access to libgcc, and you want to do so without all the hassles of
forcing everybody to upgrade their exception handling shared libraries to
test out new, experimental, features).

Backwards and forwards compatibility gets much easier if you don't try to
mix metaphors together.

		Linus