versioning of _Unwind_*() symbols

[H. J. Lu]

On Wed, Apr 21, 2004 at 02:13:39PM -0700, Mark Mitchell wrote:
> H. J. Lu wrote:
> 
> >>Since GCC has never provided this library, there are going to be 
> >>challenges here.
> >>
> >>The first step is to undo the versioning mistake.  That's a sine qua non 
> >>for anything else.  After that, someone should implement libcxa.so.  
> >>Probably, libgcc will need to depend on it, since existing programs 
> >>expect libgcc to provide these interfaces.
> >>   
> >>
> >
> >Where do those versioned definitions for backward compatibilty come
> >from? Should we consider libgcc_s.so.2?
> > 
> >
> Maybe.  If we split out the C++ support into libcxa.so at that time we 
> could perhaps  clean up some of this mess.  The way it should be is that 
> libcxa.so should contain the C++ ABI stuff, and libgcc_s.so should 
> contain stuff like math support functions and the exception personality 
> routines.
> 

If C++ ABI only specifies the shared unwind library, compilers have
less control over what unwind library will be used by executable. Also
it is good for compiler vendors since they don't have to ship their
own unwind libraries and use the standard one instead. So it is more an
issue that different compilers don't have to use their own unwind
libraries and use the standard one instead than different compilers can
use their own unwind libraries. Basically, the unwind library can be
treated as the C library. That is any C++ ABI compliant unwind library
should work with any C++ ABI compliant compilers. There is no strong
reason for a C++ ABI compliant compiler to ship their own unwind
library if there is a C++ ABI compliant system unwind library.

Assuming the unwind library will be a standard library like the C
library, symbol versioning will be a good thing for the standard
library. But it shouldn't use version name like GCC or GLIBC.


H.J.