Re: versioning of _Unwind_*() symbols

[Jim Wilson <wilson at specifixinc dot com>]

David Mosberger wrote:
> Why are the _Unwind_*() symbols being versioned?
> Do the GCC developers care about C++ ABI compatibility?

Yes, we care about C++ ABI compatibility.

I am not a library expert, so I don't know all of the ramifications of 
versioning symbols, but my understanding is that it is standard practice 
to version symbols exported by standard shared libraries.  If we ever 
find a mistake, and need to fix a bug or change an interface, then the 
versioning helps us ensure that programs and/or shared libraries linked 
against the old version of the function still get the old version of the 
function.

The situation here is a bit special.  We added routines to libgcc which 
are required by C++ ABI.  Then you contributed patches to remove them 
from libgcc and replace them with equivalent versions from libunwind. 
Unfortunately, this means anything linked against an old version of 
libgcc can no longer find the old routines they need.  This implies that 
removing the routines from libgcc was wrong.

Note that glibc does the same thing as libgcc, it versions all exported 
standard functions put in libc.so.  Suppose someone writes their own 
memcpy function which is better than the one in libc.so, and then 
relinks libc.so to remove the glibc memcpy function.  What happens? 
Programs linked against the old libc.so no longer work, because they 
can't find the glibc versioned mempcy function anymore.  It seems to 
make sense that relinking glibc to remove functions is wrong, and by 
extension, it is also wrong for libgcc.

So it seems that libgcc wasn't doing anything wrong, rather our attempt 
to remove functions from libgcc to save space was wrong.  We can remove 
them from libgcc.a, but not from libgcc_s.so.

This seems to match with Mark's suggestion of putting the functions back 
in libgcc_s.so to maintain backwards compatibility.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com