versioning of _Unwind_*() symbols

[Mark Mitchell]

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