Re: versioning of _Unwind_*() symbols

[Mark Mitchell <mark at codesourcery dot com>]

H. J. Lu wrote:

> On Wed, Apr 21, 2004 at 12:34:30PM -0700, Mark Mitchell wrote:
>  
>
> > Daniel Jacobowitz wrote:
> >
> >    
> >
> > > On Wed, Apr 21, 2004 at 12:15:16PM -0700, Mark Mitchell wrote:
> > >
> > >
> > >      
> > >
> > > > > 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?
> > > > >
> > > > >
> > > > >    
> > > > >
> > > > >          
> > > > The presonality routines should be either (a) included in the shared 
> > > > object or executable, or (b)  the shared object or executable should 
> > > > have a dependency on a shared object providing that personality routine.
> > > >  
> > > >
> > > >        
> > > It seems to me that we need to sit down and think about what kinds of
> > > "compatibility" are really guaranteed by the ABI before we make any
> > > changes in this area.  For instance, we currently satisfy references to
> > > the unwind symbols (on ELF platforms, this is) by adding a DT_NEEDED
> > > referring to "libgcc_s.so.1".  Does that violate the ABI?  If not,
> > > perhaps versioning the symbols doesn't either.
> > >
> > >      
> > No, that doesn't violate the ABI.  The is built atop whatever other ABIs 
> > are on the platform.  On  IA32 GNU/Linux (say), ELF with DT_NEEDED is 
> > part of the system ABI, so using it is just fine.  Your program can 
> > depend on whatever shared objects it wants to, including libgcc.
> >
> > The C++ runtime support library (containing __cxa_* and _Unwind_*) is 
> > special; the ABI specifically is designed to allow any compiler to 
> > generate code that will work with any support library.  I don't think 
> > the use of versioned symbols allows that; it means, concretely, that 
> > Intel would have to emit references to versioned symbols in the code 
> > that icc generates.  That didn't use to be the case, and it shouldn't be 
> > the case now.
> >
> >    
>
> If we are building a shared library with DT_NEEDED pointed to the
> unwind library called "libgcc_s.so.1", how can another compiler use
> their unwind library, saying libmyunwind, with this DSO? If the C++
> ABI covers unwind with shared library and executable, it should also
> specify how the unwind library should be handled at link time as well
> as at run time.
>  
The ABI says:

An implementation shall place its standard support library in a DSO 
named |libcxa.so| on Itanium systems, or in auxiliary DSOs automatically 
loaded by it.  It shall place implicit compiler support in a library 
separate from the standard support library, with any external names 
chosen to avoid conflicts between vendors (e.g. by including a vendor 
identifier as part of the names).

The reference to "Itanium" is accidental.

GCC, for whatever reason, has never provided libcxa.so.  That library 
should contain all of the C++ ABI stuff, and should be *completely 
interchangeable* between vendor implementations.  The complete set of 
interfaces and the behavior of those interfaces is specified by the C++ 
ABI.  It should not matter whose libcxa.so you get; if it does matter 
either your program or the libcxa.so implementation you're using has a bug.

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.

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com