This is the mail archive of the
mailing list for the GCC project.
Re: versioning of _Unwind_*() symbols
On Wed, Apr 21, 2004 at 10:54:11AM -0700, Mark Mitchell wrote:
> Gabriel Dos Reis wrote:
> >Jim Wilson <firstname.lastname@example.org> writes:
> >| I fail to see any difference between what glibc does and what libgcc
> >| does.
> >I believe the main difference is that libgcc is tightly coupled with
> >the compiler and glibc is more much decoupled. libgcc is fixed by the
> >compiler. That makes its versioning more debatable.
> >I'm not sure we can reason on what glibc does and transpose the
> >outcome to libgcc.
> I agree with David Mosberger.
> I think that it was a mistake to version the symbols. The C++ ABI is
> designed so that compilers can interoperate; clearly, if GCC-compiled
> objects contain references to versioned symbols, then other compilers
> cannot easily provide matching runtime libraries, and vice versa.
We have to be very careful this time. Otherwise, we may mix 2 unwind
libraries by accident. The same gcc compiler source can be configured
with or without libunwind.
While we are on it, binaries compiled by gcc may reference gcc
personality functions, which only come with gcc. That means when you
mix them with other compilers, you have to do something like
# icc .... find the right gcc personality functions
How can we address this?
> If these functions need to change in some way that would normally
> require using a versioned symbol, the functions must instead be renamed.
Are you suggesting to change the C++ ABI in this case? If it is the
case, shouldn't the C++ ABI be modified to reflect that? I guess
those implementation who do it right will have to cope :-(.
> Therefore, I think we need to do two things:
> (1) Put the unversioned symbols back in libgcc, and or make libgcc
> depend on libunwind, thereby making sure that the symbols will be available.
> (2) Keep the versioned symbols that we have now because there might be
> (ABI-incompatible) code that depends upon them.