This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: __register_frame_info & shared library compatibility
- To: Jamie Lokier <egcs@tantalophile.demon.co.uk>
- Subject: Re: __register_frame_info & shared library compatibility
- From: Jeffrey A Law <law@cygnus.com>
- Date: Thu, 08 Apr 1999 14:20:11 -0600
- cc: "H.J. Lu" <hjl@lucon.org>, egcs@egcs.cygnus.com, GNU C Library <libc-hacker@cygnus.com>
- Reply-To: law@cygnus.com
In message <19990408222418.C21807@pcep-jamie.cern.ch>you write:
> The danger is that we get locked in to including bloat in all binaries,
> that can't ever be removed. I'm interested in a solution to that long
> term problem. If we have to include the bloat in the interim to provide
> binary compatibility, that is fine.
We already know at some point we will have to break binary compatibility in
the future to get some new C++ features. That would be the time to drop the
old interfaces.
But in general, if an interface is added with external scope in libgcc, then it
has to stay indefinitely (until the next planned binary breakage). Thus we
have to be a *LOT* more careful about what interfaces we put in that library --
we don't want to plan many binary breakages.
> Though frankly, the bloat due to the redundant .eh_frame in C binaries
> much more significant. Is throwing an exception through C really
> supposed to have defined behaviour?
?!? I don't think we create eh_frames for C code by default now. We do
if one specifies -fexceptions though.
jeff