This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: need for flag for incompatible-changes
- To: Joe Buck <jbuck at synopsys dot com>
- Subject: Re: need for flag for incompatible-changes
- From: Andi Kleen <ak at muc dot de>
- Date: 29 Jan 1998 22:45:06 +0100
- Cc: pkoning at xedia dot com (Paul Koning), jhpb at sarto dot gaithersburg dot md dot us, egcs at cygnus dot com
- References: <199801282008.MAA03266@atrus.synopsys.com>
Joe Buck <jbuck@synopsys.com> writes:
> > If object files contained version numbers, you wouldn't have to break
> > anything. (More precisely, you would only have to break things that
> > are older than the oldest version you want to continue supporting in
> > the linker.)
>
> Where we have control over the linker (Linux, or platforms where GNU ld
> will work), we could use the linker to handle some types of
> incompatibilities. In many cases, I'm afraid that all it will lets
> us do is say "sorry, incompatible object files".
I'm not sure if it is a good idea to let the linker know about intime
details of the exception table format. Looks like a strong layering
violation for me.
The correct way to solve this IMHO is to use the ELF Symbol versioning
support in binutils 2.8. It was exactly designed to solve problems
like this. In the worst case object files will grow a bit because
they'll contain two copies of the exception table, but not the
resulting executable because the linker will select the correct one
using the matching symbols.
[Afaik the current exception table works using a section instead of
symbols, but maybe the symbol versioning support can be extended for
section names too?]
-Andi