Re: versioning of _Unwind_*() symbols

[David Mosberger <davidm at napali dot hpl dot hp dot com>]

>>>>> On Thu, 22 Apr 2004 09:36:36 -0700, Mark Mitchell <mark@codesourcery.com> said:

  Mark> However, we shouldn't call this the unwind library.  In addition to
  Mark> unwinding routines, it contains things operator new/delete and
  Mark> __cxa_dynamic_cast.  Let's call it the ABI library.

As long as the "ABI library" may consist of a separate unwind-library,
I'm OK with that.  Note that both HP-UX and the Intel compiler on
Linux use a separate libunwind.so to provide the actual unwinder.  My
unwind library also provides (a plugin-compatible) libunwind.so and it
cannot & should not implement C++ specific runtime support, so it
seems to me that it makes tons of sense to split up the cxa_*() and
_Unwind*() routines.  Of course, libcxa.so can (must?) have a
dependency on libunwind.so, so that if you load libcxa.so, you'll get
_Unwind*() along with it.

  Mark> There may be good reasons for having a compiler-specific
  Mark> personality routine, but that would not be part of the ABI
  Mark> library.  It is possible that some ABI libraries will be more
  Mark> efficient than others, so a compiler might want to provide a
  Mark> version that is superior.  But, if a user chooses to use the
  Mark> system one instead, their programs will still work.

Note that the Intel compiler provides __gxx_personality_v0() in its
own library.  I suspect that's not right, but probably it is/was the
only way for the Intel compiler to be interoperable with GCC-compiled
C++ code.

  >> 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.

  Mark> I don't agree with this statement.

  Mark> It means that users cannot replace the system ABI library with
  Mark> one provided by another compiler.

  Mark> The way that the ABI contemplates dealing with versioning is
  Mark> by creating new function names.  That may be considered
  Mark> inferior and primitive, but it is the way that it is.  Any
  Mark> problem that would require a new version number on GNU/Linux
  Mark> will require a new function name on other systems.  So, using
  Mark> version numbers will just make things different across systems
  Mark> for no good reason.

I very much agree with Mark here.  Especially considering that
versioned symbols have some "interesting" problems, as pointed out by
HJ's bug report here:

  http://sources.redhat.com/ml/libc-alpha/2003-09/msg00154.html

The followup by Uli Drepper seems to indicate that the glibc
developers have no interest in fixing this issue.

In other words: even _if_ the ABI-committee agreed to allow for
versioned symbols, there would still be potential problems in using
them on glibc-based systems.  Usage scenarios that would work with
unversioned symbols might not work with versioned symbols.

	--david