This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: need for flag for incompatible-changes


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]