This is the mail archive of the
mailing list for the GCC project.
Re: versioning of _Unwind_*() symbols
- From: Jim Wilson <wilson at specifixinc dot com>
- To: davidm at hpl dot hp dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 20 Apr 2004 15:40:25 -0700
- Subject: Re: versioning of _Unwind_*() symbols
- References: <email@example.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
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