versioning of _Unwind_*() symbols

versioning of _Unwind_*() symbols

[David Mosberger]

In reference to this bug report:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14925

Why are the _Unwind_*() symbols being versioned?
Do the GCC developers care about C++ ABI compatibility?

	--david

Re: versioning of _Unwind_*() symbols

[Jim Wilson]

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

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

Re: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On Tue, 20 Apr 2004 15:40:25 -0700, Jim Wilson <wilson@specifixinc.com> said:

  Jim> So it seems that libgcc wasn't doing anything wrong, rather our
  Jim> attempt to remove functions from libgcc to save space was
  Jim> wrong.  We can remove them from libgcc.a, but not from
  Jim> libgcc_s.so.

When built against libunwind, libgcc_s.so should have a dependency
on libunwind.so and hence no symbols got lost.

However, there is still a versioning issue.  AFAIK, the C++ ABI
doesn't specify (allow?) versioned symbols.  Certainly Intel's
_Unwind_*() routines also are not versioned.

	--david

Re: versioning of _Unwind_*() symbols

[Jim Wilson]

On Tue, 2004-04-20 at 16:06, David Mosberger wrote:
> When built against libunwind, libgcc_s.so should have a dependency
> on libunwind.so and hence no symbols got lost.

The old versions of the functions were lost.

> However, there is still a versioning issue.  AFAIK, the C++ ABI
> doesn't specify (allow?) versioned symbols.  Certainly Intel's
> _Unwind_*() routines also are not versioned.

You seem to have glossed over the glibc comments here.  glibc versions
symbols.  If glibc can and does version symbols, then it seems to me
that libgcc also can and should version symbols.  Do the ANSI or POSIX
standards say anything about symbol versioning?  I doubt that they do. 
Hence whether the C++ ABI says anything about versioning is irrelevant.

Versioning is a system issue.  In order to provide compatibility from
one gcc/glibc version to the next, we version symbols.  I see nothing
wrong with this.

As I mentioned before, the only problem here seems to be that we dropped
symbols from libgcc to save space.  But this loses compatibility, which
is a bigger problem than saving space, so we should put the symbols
back.  This won't break libunwind, as libunwind is linked in before
libgcc, so we still get the libunwind versions of the routines if
libunwind has them.

If a system vendor chooses to ship libunwind as a required part of a
linux distro, then and only then, can we drop the symbols from libgcc,
as then we no longer need them for compatibility with the system version
of libgcc_s.so.  This assumes we don't need compatibility with previous
linux distro releases, and/or there is a separate libgcc_s.so for
compatibility with old linux distro releases.

Note that one way to get libunwind accepted as a standard part of a
linux distro is to add it to a package that is already a standard part
of a linux distro.  This will be a lot of FSF paperwork though.  libffi
is technically not part of gcc, and some people have been trying to fix
this for about 9 months with no apparent success so far.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Tue, Apr 20, 2004 at 03:40:25PM -0700, Jim Wilson wrote:
> 
> This seems to match with Mark's suggestion of putting the functions back 
> in libgcc_s.so to maintain backwards compatibility.

It is a very tricky thing to do with the current Linux dynamic linker.
Those removed functions should be restored. The question is where
they come from. We can't use the old definiton since we want to use
the ones in libunwind. In glibc, we do

foo ()
{
  h = dlopen (libgcc)
  fn = dlsym (h, "foo");
  (*fn) ...
}

so that we can define foo in glibc as a wrapper for foo in libgcc.
Maybe we can do the same for libgcc.


H.J.

Re: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On Tue, 20 Apr 2004 16:28:02 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> On Tue, Apr 20, 2004 at 03:40:25PM -0700, Jim Wilson wrote:

  >> This seems to match with Mark's suggestion of putting the functions back
  >> in libgcc_s.so to maintain backwards compatibility.

  HJ> It is a very tricky thing to do with the current Linux dynamic linker.
  HJ> Those removed functions should be restored. The question is where
  HJ> they come from. We can't use the old definiton since we want to use
  HJ> the ones in libunwind. In glibc, we do

  HJ> foo ()
  HJ> {
  HJ> h = dlopen (libgcc)
  HJ> fn = dlsym (h, "foo");
  HJ> (*fn) ...
  HJ> }

  HJ> so that we can define foo in glibc as a wrapper for foo in libgcc.
  HJ> Maybe we can do the same for libgcc.

I didn't think libgcc could/should rely on dlopen()?

But in any case, for libgcc_s.so, it's sufficient to have a dependency
on libunwind.so.  The dynamic linker will then take care of loading
libunwind.so before loading libgcc_s.so.

	--david

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Tue, Apr 20, 2004 at 04:35:46PM -0700, David Mosberger wrote:
> >>>>> On Tue, 20 Apr 2004 16:28:02 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
>   HJ> On Tue, Apr 20, 2004 at 03:40:25PM -0700, Jim Wilson wrote:
> 
>   >> This seems to match with Mark's suggestion of putting the functions back
>   >> in libgcc_s.so to maintain backwards compatibility.
> 
>   HJ> It is a very tricky thing to do with the current Linux dynamic linker.
>   HJ> Those removed functions should be restored. The question is where
>   HJ> they come from. We can't use the old definiton since we want to use
>   HJ> the ones in libunwind. In glibc, we do
> 
>   HJ> foo ()
>   HJ> {
>   HJ> h = dlopen (libgcc)
>   HJ> fn = dlsym (h, "foo");
>   HJ> (*fn) ...
>   HJ> }
> 
>   HJ> so that we can define foo in glibc as a wrapper for foo in libgcc.
>   HJ> Maybe we can do the same for libgcc.
> 
> I didn't think libgcc could/should rely on dlopen()?
> 
> But in any case, for libgcc_s.so, it's sufficient to have a dependency
> on libunwind.so.  The dynamic linker will then take care of loading
> libunwind.so before loading libgcc_s.so.
> 

The current Linux dynamic linker may or may not allow you to move a
versioned definition from one DSO to another:

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



H.J.

Re: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On Tue, 20 Apr 2004 16:41:52 -0700, "H. J. Lu" <hjl@lucon.org> said:

  >> But in any case, for libgcc_s.so, it's sufficient to have a dependency
  >> on libunwind.so.  The dynamic linker will then take care of loading
  >> libunwind.so before loading libgcc_s.so.

  HJ> The current Linux dynamic linker may or may not allow you to move a
  HJ> versioned definition from one DSO to another:

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

But if the _Unwind_*() symbols weren't versioned in the first
place, there would be no problem at all.

I do understand that versioning may make sense in _general_, but we're
talking about the C++ _ABI_ here.  If it's not _binary_ compatible,
then it's simply not compatible.  No?

	--david

Re: versioning of _Unwind_*() symbols

[Jim Wilson]

On Tue, 2004-04-20 at 16:51, David Mosberger wrote:
> I do understand that versioning may make sense in _general_, but we're
> talking about the C++ _ABI_ here.  If it's not _binary_ compatible,
> then it's simply not compatible.  No?

Why does glibc bother to versions symbols when they are all binary
compatible?

The answer is that while the intent is for everything to be binary
compatible, we occasionally find bugs, and the symbol versioning allows
us to fix bugs without losing backwards compatibility.  Also, standards
occsionally change, and this presumably allows for some compatibility
across standards.

We have incidentally found a number of bugs in the C++ ABI simply by
comparing the HP, Intel, and GNU C++ compilers against each other.  Some
of these problems have required compiler changes.  Some of them have
required C++ ABI changes.  I think all of these compilers are known to
have at least one bug that prevents them from being fully compliant, and
some (e.g. the HP one) may never be fixed, because of backwards
compatibility problems.

There is also the issue that we have extensions to the C++ ABI, as we
ran into problems making C++ exceptions work with thread cancellation.

What is wrong with putting the symbols back in libgcc_s.so?  If you link
with libunwind before libgcc, programs will use the libunwind versions
won't they?

Maybe the issue is that system libraries that were linked again libgcc
will still use the libgcc version?  That gets us back to the issue I
mentioned before, which is that this is really a system packaging issue,
not a libgcc vesioning issue.  If a linux distro ships with libunwind as
a standard package, then everything is OK.  If libunwind is an add on
package, then we can't replace the versioned libgcc functions, we can
only replace the internal unversioned functions.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: versioning of _Unwind_*() symbols

[Daniel Jacobowitz]

On Tue, Apr 20, 2004 at 05:26:02PM -0700, Jim Wilson wrote:
> Why does glibc bother to versions symbols when they are all binary
> compatible?
> 
> The answer is that while the intent is for everything to be binary
> compatible, we occasionally find bugs, and the symbol versioning allows
> us to fix bugs without losing backwards compatibility.  Also, standards
> occsionally change, and this presumably allows for some compatibility
> across standards.

The latter issue is not a problem here.  Presumably, the former isn't
either - a standard has to take the pre-symbol-versioning approach of
simply renaming functions when their signatures or behavior change
significantly.

> What is wrong with putting the symbols back in libgcc_s.so?  If you link
> with libunwind before libgcc, programs will use the libunwind versions
> won't they?

Dubious - behavior with both versioned and unversioned definitions
present can be pretty random.

> Maybe the issue is that system libraries that were linked again libgcc
> will still use the libgcc version?  That gets us back to the issue I
> mentioned before, which is that this is really a system packaging issue,
> not a libgcc vesioning issue.  If a linux distro ships with libunwind as
> a standard package, then everything is OK.  If libunwind is an add on
> package, then we can't replace the versioned libgcc functions, we can
> only replace the internal unversioned functions.

The issue that I see is that code linked against libgcc's
implementation of the C++ ABI can not be used with anyone else's
implementation of the C++ ABI.  If that is not binary incompatibility,
then what do you think is?  Putting explicit "GCC_3.x" identifiers on
the symbol reference means that the binary demands GCC's implementation
and demands that it come from libgcc_s.so.1.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: versioning of _Unwind_*() symbols

[Jim Wilson]

On Tue, 2004-04-20 at 17:45, Daniel Jacobowitz wrote:
> The issue that I see is that code linked against libgcc's
> implementation of the C++ ABI can not be used with anyone else's
> implementation of the C++ ABI.

How is this any different than what glibc does?  Code linked against
glibc's implementation of the ISO C and POSIX library standards can not
be used with anyone else's implementation of the ISO C and POSIX library
standards, because glibc versions symbols.  If you didn't want to use
the routines from glibc, you shouldn't have linked them in.

I fail to see any difference between what glibc does and what libgcc
does.  Perhaps I am wrong, but no one has yet pointed out any flaw in my
argument.

Actually, come to think of it, glibc tends to use weak aliases a lot. 
Does that help solve the problem if libgcc starts using weak aliases?  I
haven't tried thinking this through.  Or perhaps there is some other
difference between how glibc and libgcc are structured that lets
versioned symbols work for glibc?
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On 20 Apr 2004 18:24:42 -0700, Jim Wilson <wilson@specifixinc.com> said:

  Jim> How is this any different than what glibc does?  Code linked against
  Jim> glibc's implementation of the ISO C and POSIX library standards can not
  Jim> be used with anyone else's implementation of the ISO C and POSIX library
  Jim> standards, because glibc versions symbols.  If you didn't want to use
  Jim> the routines from glibc, you shouldn't have linked them in.

I believe ISO C and POSIX only define APIs, not ABIs.

	--david

Re: versioning of _Unwind_*() symbols

[Daniel Jacobowitz]

On Tue, Apr 20, 2004 at 06:38:46PM -0700, David Mosberger wrote:
> >>>>> On 20 Apr 2004 18:24:42 -0700, Jim Wilson <wilson@specifixinc.com> said:
> 
>   Jim> How is this any different than what glibc does?  Code linked against
>   Jim> glibc's implementation of the ISO C and POSIX library standards can not
>   Jim> be used with anyone else's implementation of the ISO C and POSIX library
>   Jim> standards, because glibc versions symbols.  If you didn't want to use
>   Jim> the routines from glibc, you shouldn't have linked them in.
> 
> I believe ISO C and POSIX only define APIs, not ABIs.

Thank you, David.  That was precisely my point.

The LSB, for instance, defines an ABI.  I believe it _does_ account for
symbol versioning, and there are non-glibc compliant implementations.
The C++ ABI doesn't account for symbol versioning - reasonable, since
it supports non-ELF targets - but the question at hand is, does that
cut out the possibility of versioning the symbols?

I was staying out of this discussion because I don't have a clear
answer to that question, but I do think that the answer is: yes, it
does eliminate the possibility.  How to implement this properly is
unclear.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: versioning of _Unwind_*() symbols

[Gabriel Dos Reis]

Jim Wilson <wilson@specifixinc.com> 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.

-- Gaby

Re: versioning of _Unwind_*() symbols

[Mark Mitchell]

Gabriel Dos Reis wrote:

>Jim Wilson <wilson@specifixinc.com> 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. 

If these functions need to change in some way that would normally 
require using a versioned symbol, the functions must instead be renamed.

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.

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

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Wed, Apr 21, 2004 at 10:54:11AM -0700, Mark Mitchell wrote:
> Gabriel Dos Reis wrote:
> 
> >Jim Wilson <wilson@specifixinc.com> 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.
> 


H.J.

Re: versioning of _Unwind_*() symbols

[Mark Mitchell]

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

>>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 :-(.
>  
>
If the C++ ABI needs to change, then it will change.  In that case, new 
functions will be added to the ABI, and we will have to provide both the 
old and new functions.  This is no different from versioning, except 
that it's an uglier way of doing it.

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

Re: versioning of _Unwind_*() symbols

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: versioning of _Unwind_*() symbols

[Mark Mitchell]

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.

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

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

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.


H.J.

Re: 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

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Wed, Apr 21, 2004 at 01:52:07PM -0700, Mark Mitchell wrote:
> >
> >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.
> 

So it is almost totally a run-time issue. You can link against a dummy
libcxa.so if you want. It is the one picked up by the dynamic linker
counts.

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

Where do those versioned definitions for backward compatibilty come
from? Should we consider libgcc_s.so.2?


H.J.

Re: versioning of _Unwind_*() symbols

[Mark Mitchell]

H. J. Lu wrote:

>>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.
>>    
>>
>
>Where do those versioned definitions for backward compatibilty come
>from? Should we consider libgcc_s.so.2?
>  
>
Maybe.  If we split out the C++ support into libcxa.so at that time we 
could perhaps  clean up some of this mess.  The way it should be is that 
libcxa.so should contain the C++ ABI stuff, and libgcc_s.so should 
contain stuff like math support functions and the exception personality 
routines.

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

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Wed, Apr 21, 2004 at 02:13:39PM -0700, Mark Mitchell wrote:
> H. J. Lu wrote:
> 
> >>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.
> >>   
> >>
> >
> >Where do those versioned definitions for backward compatibilty come
> >from? Should we consider libgcc_s.so.2?
> > 
> >
> Maybe.  If we split out the C++ support into libcxa.so at that time we 
> could perhaps  clean up some of this mess.  The way it should be is that 
> libcxa.so should contain the C++ ABI stuff, and libgcc_s.so should 
> contain stuff like math support functions and the exception personality 
> routines.
> 

FYI, glibc does

	dlopen ("libgcc_s.so.1")

to get unwind library. Also icc has a libcxa.so, but it is not the
unwind library. We may need to take another look at C++ ABI to get
it right this time for all compilers.


H.J.

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Wed, Apr 21, 2004 at 02:13:39PM -0700, Mark Mitchell wrote:
> H. J. Lu wrote:
> 
> >>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.
> >>   
> >>
> >
> >Where do those versioned definitions for backward compatibilty come
> >from? Should we consider libgcc_s.so.2?
> > 
> >
> Maybe.  If we split out the C++ support into libcxa.so at that time we 
> could perhaps  clean up some of this mess.  The way it should be is that 
> libcxa.so should contain the C++ ABI stuff, and libgcc_s.so should 
> contain stuff like math support functions and the exception personality 
> routines.
> 

If C++ ABI only specifies the shared unwind library, compilers have
less control over what unwind library will be used by executable. Also
it is good for compiler vendors since they don't have to ship their
own unwind libraries and use the standard one instead. So it is more an
issue that different compilers don't have to use their own unwind
libraries and use the standard one instead than different compilers can
use their own unwind libraries. Basically, the unwind library can be
treated as the C library. That is any C++ ABI compliant unwind library
should work with any C++ ABI compliant compilers. There is no strong
reason for a C++ ABI compliant compiler to ship their own unwind
library if there is a C++ ABI compliant system unwind library.

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.


H.J.

Re: versioning of _Unwind_*() symbols

[Mark Mitchell]

H. J. Lu wrote:

>There is no strong
>reason for a C++ ABI compliant compiler to ship their own unwind
>library if there is a C++ ABI compliant system unwind library.
>
>  
>
I agree. 

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

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

>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.
>  
>
I don't agree with this statement. 

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

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

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

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Thu, Apr 22, 2004 at 09:36:36AM -0700, Mark Mitchell wrote:
> 
> However, we shouldn't call this the unwind library.  In addition to 
> unwinding routines, it contains things operator new/delete and 
> __cxa_dynamic_cast.  Let's call it the ABI library.
> 
> There may be good reasons for having a compiler-specific personality 
> routine, but that would not be part of the ABI library.  It is possible 
> that some ABI libraries will be more efficient than others, so a 
> compiler might want to provide a version that is superior.  But, if a 
> user chooses to use the system one instead, their programs will still work.
> 
> >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.
> > 
> >
> I don't agree with this statement. 
> 
> It means that users cannot replace the system ABI library with one 
> provided by another compiler.
> 
> The way that the ABI contemplates dealing with versioning is by creating 
> new function names.  That may be considered inferior and primitive, but 
> it is the way that it is.  Any problem that would require a new version 
> number on GNU/Linux will require a new function name on other systems.  
> So, using version numbers will just make things different across systems 
> for no good reason.
> 

Versioning can be used for 2 things:

1. Change ABI.
2. Fix implementation.

We don't need versioning to change ABI here. But it is still useful to
fix implementation. That is you have a broken implementation, but you
can't change the implementation since some binaries depend on the old
broken behavior. Symbol versioning allows you to fix the implementation
without breaking those old binaries.


H.J.

Re: versioning of _Unwind_*() symbols

[Mark Mitchell]

H. J. Lu wrote:

>We don't need versioning to change ABI here. But it is still useful to
>fix implementation. That is you have a broken implementation, but you
>can't change the implementation since some binaries depend on the old
>broken behavior. Symbol versioning allows you to fix the implementation
>without breaking those old binaries.
>
I don't necessarily see that as a good idea.  If, for example, "operator 
new" were to be broken, then old binaries that use the broken version 
might crash sometimes.  Providing a fixed version of "operator new" 
would help those binaries, not hurt them.  There might be some other old 
binaries that would somehow now fail, but why should we expect there 
would be more binaries in the latter class thant he former?

And, there remains the issue that using versioning means that other 
compilers cannot easily provide a drop-in replacement for libcxa.so, 
even if they have a good reason (performance, for example) for doing so.

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

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Thu, Apr 22, 2004 at 10:07:36AM -0700, Mark Mitchell wrote:
> H. J. Lu wrote:
> 
> >We don't need versioning to change ABI here. But it is still useful to
> >fix implementation. That is you have a broken implementation, but you
> >can't change the implementation since some binaries depend on the old
> >broken behavior. Symbol versioning allows you to fix the implementation
> >without breaking those old binaries.
> >
> I don't necessarily see that as a good idea.  If, for example, "operator 
> new" were to be broken, then old binaries that use the broken version 
> might crash sometimes.  Providing a fixed version of "operator new" 
> would help those binaries, not hurt them.  There might be some other old 

I was not talking about those binaries.

> binaries that would somehow now fail, but why should we expect there 
> would be more binaries in the latter class thant he former?

It is not about the numbers. It is binary compatibility. For every
reported breakage, it may affect many people.

> 
> And, there remains the issue that using versioning means that other 
> compilers cannot easily provide a drop-in replacement for libcxa.so, 
> even if they have a good reason (performance, for example) for doing so.

It is very trivial to provide versioning. If they can build a shared
library on Linux, they can add versioning in 2 minutes. I can provide
assistance to any compiler vendor if needed.


H.J.

Re: versioning of _Unwind_*() symbols

[Mark Mitchell]

H. J. Lu wrote:

>>>      
>>>
>>I don't necessarily see that as a good idea.  If, for example, "operator 
>>new" were to be broken, then old binaries that use the broken version 
>>might crash sometimes.  Providing a fixed version of "operator new" 
>>would help those binaries, not hurt them.  There might be some other old 
>>    
>>
>
>I was not talking about those binaries.
>  
>
You can't know which binaries you'd affect.  If you fix an 
implementation bug in an existing function, without changing the 
version, you'll help some binaries and you may hurt others.

In my opinion, it makes sense to have the change affect all binaries.

These functions are very fundamental.  They're like "strlen".  If we 
found a bug in "strlen", would fixing it in libc result in changing the 
version number of that symbol? 

In fact, if you discover a bug in these ABI functions, you are likely to 
have uncovered a security bug.  It's quite possible that a program which 
gets an incorrect answer from an ABI function will do something it 
should not.  If you version the symbol, then fixing the bug will not fix 
the security bug.  You will have to go recompile all the programs on the 
system that use the ABI function in order to get the fix.

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

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Thu, Apr 22, 2004 at 10:38:35AM -0700, Mark Mitchell wrote:
> H. J. Lu wrote:
> 
> >>>     
> >>>
> >>I don't necessarily see that as a good idea.  If, for example, "operator 
> >>new" were to be broken, then old binaries that use the broken version 
> >>might crash sometimes.  Providing a fixed version of "operator new" 
> >>would help those binaries, not hurt them.  There might be some other old 
> >>   
> >>
> >
> >I was not talking about those binaries.
> > 
> >
> You can't know which binaries you'd affect.  If you fix an 
> implementation bug in an existing function, without changing the 
> version, you'll help some binaries and you may hurt others.
> 
> In my opinion, it makes sense to have the change affect all binaries.
> 
> These functions are very fundamental.  They're like "strlen".  If we 
> found a bug in "strlen", would fixing it in libc result in changing the 
> version number of that symbol? 
> 
> In fact, if you discover a bug in these ABI functions, you are likely to 
> have uncovered a security bug.  It's quite possible that a program which 
> gets an incorrect answer from an ABI function will do something it 
> should not.  If you version the symbol, then fixing the bug will not fix 
> the security bug.  You will have to go recompile all the programs on the 
> system that use the ABI function in order to get the fix.
> 

Your example shows how versioning will help here. If the existing
programs can't pass the security audit without recompiling after
fixing the ABI implemenation, we can change the version without
providing the old version for backward compatibilty, those programs
won't post a security risk since they can't run. Or we can put
a warning message in the old version if the risk is relatively low.

Without versioning, it won't be easy to fix the security bug in the
implemenation.


H.J.

Re: versioning of _Unwind_*() symbols

[Mark Mitchell]

H. J. Lu wrote:

>Your example shows how versioning will help here. If the existing
>programs can't pass the security audit without recompiling after
>fixing the ABI implemenation, we can change the version without
>providing the old version for backward compatibilty, those programs
>won't post a security risk since they can't run. Or we can put
>a warning message in the old version if the risk is relatively low.
>
>Without versioning, it won't be easy to fix the security bug in the
>implemenation.
>  
>
I understand your argument, but I don't find it compelling.  Doing what 
you suggest would cause a lot of programs that work just fine -- with or 
without the change -- to stop working.

I think it's time for us to agree to disagree.

In any case, this issue is in the noise.  One key issue to solve is 
getting libcxa.so out of libgcc, and putting just the ABI-required 
symbols in that library.  Once that gets done, we can figure out what to 
do next.   A second key issue is fixing the backwards compatibility 
problem we already have due to the fact that the symbols in libgcc are 
now versioned.  Let's work on those issues first.  Then, we can decide 
whether or not to version the symbols in libcxa.

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

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Thu, Apr 22, 2004 at 10:58:57AM -0700, Mark Mitchell wrote:
> H. J. Lu wrote:
> 
> >Your example shows how versioning will help here. If the existing
> >programs can't pass the security audit without recompiling after
> >fixing the ABI implemenation, we can change the version without
> >providing the old version for backward compatibilty, those programs
> >won't post a security risk since they can't run. Or we can put
> >a warning message in the old version if the risk is relatively low.
> >
> >Without versioning, it won't be easy to fix the security bug in the
> >implemenation.
> > 
> >
> I understand your argument, but I don't find it compelling.  Doing what 
> you suggest would cause a lot of programs that work just fine -- with or 
> without the change -- to stop working.

I think there is a misconception here. It won't happen if we do it
right. We have lots of experiences on Linux.

> 
> I think it's time for us to agree to disagree.
> 

Agreed.

> In any case, this issue is in the noise.  One key issue to solve is 
> getting libcxa.so out of libgcc, and putting just the ABI-required 
> symbols in that library.  Once that gets done, we can figure out what to 
> do next.   A second key issue is fixing the backwards compatibility 
> problem we already have due to the fact that the symbols in libgcc are 
> now versioned.  Let's work on those issues first.  Then, we can decide 
> whether or not to version the symbols in libcxa.

Those 2 issues are tied together. I think we may have to move to
libgcc_s.so.2. If we have more control over the ABI library, we may be
to able do something like:

1. The ABI library provides separate entries for those backward
compatibility functions.
2. libgcc_s.so.1 defines those old backward compatibility functions
as wrappers of the real ones in the ABI library.


H.J.

H.J.

Re: versioning of _Unwind_*() symbols

[Mark Mitchell]

H. J. Lu wrote:

>>In any case, this issue is in the noise.  One key issue to solve is 
>>getting libcxa.so out of libgcc, and putting just the ABI-required 
>>symbols in that library.  Once that gets done, we can figure out what to 
>>do next.   A second key issue is fixing the backwards compatibility 
>>problem we already have due to the fact that the symbols in libgcc are 
>>now versioned.  Let's work on those issues first.  Then, we can decide 
>>whether or not to version the symbols in libcxa.
>>    
>>
>
>Those 2 issues are tied together. I think we may have to move to
>libgcc_s.so.2. If we have more control over the ABI library, we may be
>to able do something like:
>
>1. The ABI library provides separate entries for those backward
>compatibility functions.
>2. libgcc_s.so.1 defines those old backward compatibility functions
>as wrappers of the real ones in the ABI library.
>  
>
I'd rather see the ABI library contain just the functions the ABI 
requires it to contain.  Put the backwards compatibility stuff in 
libgcc.so.  I'm not sure about whether or not we need to bump the 
version number on libgcc.so -- but I could believe that we have to do so.

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

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Thu, Apr 22, 2004 at 02:39:37PM -0700, Mark Mitchell wrote:
> H. J. Lu wrote:
> 
> >>In any case, this issue is in the noise.  One key issue to solve is 
> >>getting libcxa.so out of libgcc, and putting just the ABI-required 
> >>symbols in that library.  Once that gets done, we can figure out what to 
> >>do next.   A second key issue is fixing the backwards compatibility 
> >>problem we already have due to the fact that the symbols in libgcc are 
> >>now versioned.  Let's work on those issues first.  Then, we can decide 
> >>whether or not to version the symbols in libcxa.
> >>   
> >>
> >
> >Those 2 issues are tied together. I think we may have to move to
> >libgcc_s.so.2. If we have more control over the ABI library, we may be
> >to able do something like:
> >
> >1. The ABI library provides separate entries for those backward
> >compatibility functions.
> >2. libgcc_s.so.1 defines those old backward compatibility functions
> >as wrappers of the real ones in the ABI library.
> > 
> >
> I'd rather see the ABI library contain just the functions the ABI 
> requires it to contain.  Put the backwards compatibility stuff in 
> libgcc.so.  I'm not sure about whether or not we need to bump the 
> version number on libgcc.so -- but I could believe that we have to do so.
> 

Are you suggesting to have 2 unwind libraries at run-time, one for
backwards compatibility in libgcc.so and the new one in the ABI
library?

BTW, since the ABI library is more than just unwind library. We
can't use David's unwind library as is. Also his unwind library
is a link-time replacement, not run-time replacement for existing
unwind library in icc.


H.J.

Re: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> BTW, since the ABI library is more than just unwind library. We
  HJ> can't use David's unwind library as is.

You can.  Just list -lunwind as a dependency as is done now with libgcc_s.

  HJ> Also his unwind library is a link-time replacement, not run-time
  HJ> replacement for existing unwind library in icc.

That's not true any longer: with the libunwind in the bk repository
(due to be released as v0.97 any day now), my libunwind can serve as a
direct replacement for Intel's libunwind.  The only left-over wrinkle
at the moment is that Intel's major version is 6 whereas mine has
version 1.  I'm not sure what to do about that.  Perhaps we should all
just use 6 since the actual version doesn't matter?

	--david

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote:
> >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
>   HJ> BTW, since the ABI library is more than just unwind library. We
>   HJ> can't use David's unwind library as is.
> 
> You can.  Just list -lunwind as a dependency as is done now with libgcc_s.

I don't think it will work AS IS since linker may add libunwind.so to
DT_NEEDED if it is used. A new linker option may be needed to work
with it.

> 
>   HJ> Also his unwind library is a link-time replacement, not run-time
>   HJ> replacement for existing unwind library in icc.
> 
> That's not true any longer: with the libunwind in the bk repository
> (due to be released as v0.97 any day now), my libunwind can serve as a
> direct replacement for Intel's libunwind.  The only left-over wrinkle
> at the moment is that Intel's major version is 6 whereas mine has
> version 1.  I'm not sure what to do about that.  Perhaps we should all
> just use 6 since the actual version doesn't matter?

It may not matter if we can make sure DT_NEEDED entry in the ABI
library never shows up in executable or shared library.


H.J.

Re: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On Thu, 22 Apr 2004 16:15:12 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote:
  >> >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> BTW, since the ABI library is more than just unwind library. We
  HJ> can't use David's unwind library as is.

  >> You can.  Just list -lunwind as a dependency as is done now with libgcc_s.

  HJ> I don't think it will work AS IS since linker may add libunwind.so to
  HJ> DT_NEEDED if it is used. A new linker option may be needed to work
  HJ> with it.

Ah, you're worried that linking against libcxa.so would cause a
DT_NEEDED entry for libunwind.so in the _executable_?  I agree that's
not ideal, but it's already happening with the Intel compiler, so in
that sense it's nothing new.  If that could be avoided, I suppose it
would be great.

	--david

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Thu, Apr 22, 2004 at 04:34:25PM -0700, David Mosberger wrote:
> >>>>> On Thu, 22 Apr 2004 16:15:12 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
>   HJ> On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote:
>   >> >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
>   HJ> BTW, since the ABI library is more than just unwind library. We
>   HJ> can't use David's unwind library as is.
> 
>   >> You can.  Just list -lunwind as a dependency as is done now with libgcc_s.
> 
>   HJ> I don't think it will work AS IS since linker may add libunwind.so to
>   HJ> DT_NEEDED if it is used. A new linker option may be needed to work
>   HJ> with it.
> 
> Ah, you're worried that linking against libcxa.so would cause a
> DT_NEEDED entry for libunwind.so in the _executable_?  I agree that's

It means you can't use a different ABI library which doesn't depend
on a separate unwind library.

> not ideal, but it's already happening with the Intel compiler, so in
> that sense it's nothing new.  If that could be avoided, I suppose it
> would be great.


H.J.

Re: versioning of _Unwind_*() symbols

[Daniel Jacobowitz]

On Thu, Apr 22, 2004 at 04:15:12PM -0700, H. J. Lu wrote:
> On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote:
> > >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said:
> > 
> >   HJ> BTW, since the ABI library is more than just unwind library. We
> >   HJ> can't use David's unwind library as is.
> > 
> > You can.  Just list -lunwind as a dependency as is done now with libgcc_s.
> 
> I don't think it will work AS IS since linker may add libunwind.so to
> DT_NEEDED if it is used. A new linker option may be needed to work
> with it.

Are you sure that that will happen?  I don't think so.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On Thu, 22 Apr 2004 19:34:26 -0400, Daniel Jacobowitz <drow@false.org> said:

  Daniel> On Thu, Apr 22, 2004 at 04:15:12PM -0700, H. J. Lu wrote:
  >> On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote:
  >> > >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said:

  >> >   HJ> BTW, since the ABI library is more than just unwind library. We
  >> >   HJ> can't use David's unwind library as is.

  >> > You can.  Just list -lunwind as a dependency as is done now with libgcc_s.
  >> I don't think it will work AS IS since linker may add libunwind.so to
  >> DT_NEEDED if it is used. A new linker option may be needed to work
  >> with it.

  Daniel> Are you sure that that will happen?  I don't think so.

I think HJ is right.  I did try with an older GCC release that was
built with libunwind enabled.  The unwind library showed up as a
dependency of the executable even though the linker command line did
not specify -lunwind explicitly.  Perhaps it's a linker bug?

	--david

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Thu, Apr 22, 2004 at 04:50:43PM -0700, David Mosberger wrote:
> >>>>> On Thu, 22 Apr 2004 19:34:26 -0400, Daniel Jacobowitz <drow@false.org> said:
> 
>   Daniel> On Thu, Apr 22, 2004 at 04:15:12PM -0700, H. J. Lu wrote:
>   >> On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote:
>   >> > >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
>   >> >   HJ> BTW, since the ABI library is more than just unwind library. We
>   >> >   HJ> can't use David's unwind library as is.
> 
>   >> > You can.  Just list -lunwind as a dependency as is done now with libgcc_s.
>   >> I don't think it will work AS IS since linker may add libunwind.so to
>   >> DT_NEEDED if it is used. A new linker option may be needed to work
>   >> with it.
> 
>   Daniel> Are you sure that that will happen?  I don't think so.
> 
> I think HJ is right.  I did try with an older GCC release that was
> built with libunwind enabled.  The unwind library showed up as a
> dependency of the executable even though the linker command line did
> not specify -lunwind explicitly.  Perhaps it's a linker bug?
> 

The linker behavior is intentional. We can always add a new linker
switch to turn it off for the ABI library with something like

	-Wl,--no-add-needed -lABI -Wl,--add-needed


H.J.

Re: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On Thu, 22 Apr 2004 18:04:41 -0700, "H. J. Lu" <hjl@lucon.org> said:

  >>  I think HJ is right.  I did try with an older GCC release that
  >> was built with libunwind enabled.  The unwind library showed up
  >> as a dependency of the executable even though the linker command
  >> line did not specify -lunwind explicitly.  Perhaps it's a linker
  >> bug?

  HJ> The linker behavior is intentional.

What's the advantage of that behavior?

  HJ> We can always add a new linker switch to turn it off for the ABI
  HJ> library with something like

  HJ> 	-Wl,--no-add-needed -lABI -Wl,--add-needed

That seems fine to me.

	--david

Re: versioning of _Unwind_*() symbols

[David Mosberger]

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

Re: versioning of _Unwind_*() symbols

[Mark Mitchell]

David Mosberger wrote:

>>>>>>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.  
>
Yes, I think that's OK.  The ABI library should be called "libcxa.so", 
and linking against it must satisfy requests for unwind symbols, but if 
that's because libcxa.so pulls in other libraries, that's OK.

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

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

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 doesn't help when I want to use relocatable object files generated
by gcc with icc.


H.J.

Re: versioning of _Unwind_*() symbols

[Mark Mitchell]

H. J. Lu 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 doesn't help when I want to use relocatable object files generated
>by gcc with icc.
>  
>
The ABI does not cover that case.

If you look at the beginning of the ABI document, you'll see that it is 
designed only to deal with shared objects and executables.  There's no 
guarantee that you can intermix ".o" files, although that may work in 
some cases.

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

Re: versioning of _Unwind_*() symbols

[H. J. Lu]

On Tue, Apr 20, 2004 at 05:26:02PM -0700, Jim Wilson wrote:
> 
> What is wrong with putting the symbols back in libgcc_s.so?  If you link
> with libunwind before libgcc, programs will use the libunwind versions
> won't they?
> 

The old binaries don't know about libunwind.so. You can't load it
before libgcc_s.so transparently.

> Maybe the issue is that system libraries that were linked again libgcc
> will still use the libgcc version?  That gets us back to the issue I
> mentioned before, which is that this is really a system packaging issue,
> not a libgcc vesioning issue.  If a linux distro ships with libunwind as
> a standard package, then everything is OK.  If libunwind is an add on
> package, then we can't replace the versioned libgcc functions, we can
> only replace the internal unversioned functions.

It is more complicated than that. The end result is the new libgcc_s.so
is not 100% binary compatible with the old libgcc_s.so. There is no
easy way to fix it.


H.J.

PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[H. J. Lu]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On Tue, Apr 20, 2004 at 05:26:02PM -0700, Jim Wilson wrote:
> 
> What is wrong with putting the symbols back in libgcc_s.so?  If you link
> with libunwind before libgcc, programs will use the libunwind versions
> won't they?
> 

This patch puts libunwind.a in libgcc_s.so.1. The test result is at

http://gcc.gnu.org/ml/gcc-testresults/2004-04/msg00974.html

We can do it on ia64 since PIC is default on ia64.


H.J.

[-- Attachment #2: gcc-libunwind-3.patch --]
[-- Type: text/plain, Size: 1716 bytes --]

2004-04-20  H.J. Lu  <hongjiu.lu@intel.com>

	* config.gcc (ia64*-*-linux*): Use ia64/t-libunwind instead of
	t-libunwind.

	* config/ia64/t-libunwind: New file.

	* config/t-libunwind (LIB2ADDEH): Add $(srcdir)/gthr-gnat.c.

--- gcc/config.gcc.libunwind	2004-04-20 20:00:40.000000000 -0700
+++ gcc/config.gcc	2004-04-20 21:26:04.000000000 -0700
@@ -1264,7 +1264,7 @@ ia64*-*-linux*)
 	target_cpu_default="MASK_GNU_AS|MASK_GNU_LD"
 	extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o crtfastmath.o"
 	if test x"$use_libunwind_exceptions" = xyes; then
-	  tmake_file="$tmake_file t-libunwind"
+	  tmake_file="$tmake_file ia64/t-libunwind"
 	fi
 	;;
 ia64*-*-hpux*)
--- gcc/config/ia64/t-libunwind.libunwind	2004-04-20 21:27:56.000000000 -0700
+++ gcc/config/ia64/t-libunwind	2004-04-20 21:32:43.000000000 -0700
@@ -0,0 +1,13 @@
+# Override the default value from t-slibgcc-elf-ver to include
+# libunwind.a so that the resulting libgcc_s.so is 100% backward
+# compatible.
+# FIXME: libunwind.o is a kludge. 
+LIB2ADDEH = $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c \
+  $(srcdir)/gthr-gnat.c libunwind.o
+
+libunwind.o: $(GCC_PASSES)
+	$(GCC_FOR_TARGET) -nostdlib -nostartfiles -r -o $@ \
+	  -Wl,--whole-archive \
+	  `$(GCC_FOR_TARGET) --print-file-name=libunwind.a`
+	mkdir -p libgcc
+	cp $@ libgcc
--- gcc/config/t-libunwind.libunwind	2003-12-23 10:02:54.000000000 -0800
+++ gcc/config/t-libunwind	2004-04-20 21:25:51.000000000 -0700
@@ -2,4 +2,5 @@
 # so that the resulting libgcc_s.so has the necessary DT_NEEDED entry for
 # libunwind.
 SHLIB_LC = -lunwind -lc
-LIB2ADDEH = $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c
+LIB2ADDEH = $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c \
+  $(srcdir)/gthr-gnat.c

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On Tue, 20 Apr 2004 22:57:29 -0700, "H. J. Lu" <hjl@lucon.org> said:

  H> This patch puts libunwind.a in libgcc_s.so.1. The test result is at

  H> http://gcc.gnu.org/ml/gcc-testresults/2004-04/msg00974.html

  H> We can do it on ia64 since PIC is default on ia64.

I suppose that's progress, but I still think it's wrong for GCC to
version symbols that are defined by the C++ ABI.  To witness:

$ cat t.cxx
#include <stdio.h>

void
foo (void)
{
  char myarray[10];
  try
    {
      for (int n=0; n<=10; n++)
        {
          if (n>9) throw "Out of range";
          myarray[n]='z';
        }
    }
  catch (const char * str)
    {
      printf ("Exception: %s\n", str);
    }
}
$ cat main.cxx
extern void foo (void);

int
main (int argc, char **argv)
{
  foo ();
}
$ g++-3.4 -shared -export-dynamic -o t.so t.cxx
$ icc main.cxx t.so
t.so: undefined reference to `__cxa_begin_catch@CXXABI_1.3'
t.so: undefined reference to `__cxa_allocate_exception@CXXABI_1.3'
t.so: undefined reference to `_ZTIPKc@CXXABI_1.3'
t.so: undefined reference to `__gxx_personality_v0@CXXABI_1.3'
t.so: undefined reference to `__cxa_end_catch@CXXABI_1.3'
t.so: undefined reference to `__cxa_throw@CXXABI_1.3'

Here, icc is the Intel compiler (v8.0).  Unless the C++ ABI defines
symbols to be versioned with CXXABI_1.3, this just seems wrong to me.

BTW: the above compiles and links just fine with g++ v3.3.

	--david

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[Jim Wilson]

On Tue, 2004-04-20 at 22:57, H. J. Lu wrote:
> This patch puts libunwind.a in libgcc_s.so.1. The test result is at
> We can do it on ia64 since PIC is default on ia64.

IA-64 code is PIC by default.  However, it is not true that static
library code and shared library code are the same.  There are
differences because of the IA-64 ABI, for instance, the rules that say
"own" data can be put in the small data section, but what qualifies as
"own" data is different for shared libraries and static libraries.  This
stuff is controlled by the -fpic option.  You must use -fpic for all
code that goes into a shared library.  Note: -fpic has always meant
compile this code for shared libraries, this is even true on systems
like IA-64 where code is PIC by default.  There is no guarantee that
code in libunwind.a was compiled with -fpic.  I don't see how this can
work.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[H. J. Lu]

On Tue, Apr 20, 2004 at 11:38:36PM -0700, Jim Wilson wrote:
> On Tue, 2004-04-20 at 22:57, H. J. Lu wrote:
> > This patch puts libunwind.a in libgcc_s.so.1. The test result is at
> > We can do it on ia64 since PIC is default on ia64.
> 
> IA-64 code is PIC by default.  However, it is not true that static
> library code and shared library code are the same.  There are
> differences because of the IA-64 ABI, for instance, the rules that say
> "own" data can be put in the small data section, but what qualifies as
> "own" data is different for shared libraries and static libraries.  This
> stuff is controlled by the -fpic option.  You must use -fpic for all
> code that goes into a shared library.  Note: -fpic has always meant
> compile this code for shared libraries, this is even true on systems
> like IA-64 where code is PIC by default.  There is no guarantee that
> code in libunwind.a was compiled with -fpic.  I don't see how this can
> work.

We can always require to compile the static libunwind library with
-fpic.


H.J.

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On Wed, 21 Apr 2004 07:35:54 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> On Tue, Apr 20, 2004 at 11:38:36PM -0700, Jim Wilson wrote:
  >> On Tue, 2004-04-20 at 22:57, H. J. Lu wrote: > This patch puts
  >> libunwind.a in libgcc_s.so.1. The test result is at > We can do
  >> it on ia64 since PIC is default on ia64.

  >> IA-64 code is PIC by default.  However, it is not true that
  >> static library code and shared library code are the same.  There
  >> are differences because of the IA-64 ABI, for instance, the rules
  >> that say "own" data can be put in the small data section, but
  >> what qualifies as "own" data is different for shared libraries
  >> and static libraries.  This stuff is controlled by the -fpic
  >> option.  You must use -fpic for all code that goes into a shared
  >> library.  Note: -fpic has always meant compile this code for
  >> shared libraries, this is even true on systems like IA-64 where
  >> code is PIC by default.  There is no guarantee that code in
  >> libunwind.a was compiled with -fpic.  I don't see how this can
  >> work.

  HJ> We can always require to compile the static libunwind library
  HJ> with -fpic.

I really do not think this is the right approach.

	--david

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[H. J. Lu]

On Wed, Apr 21, 2004 at 08:22:41AM -0700, David Mosberger wrote:
> >>>>> On Wed, 21 Apr 2004 07:35:54 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
>   HJ> On Tue, Apr 20, 2004 at 11:38:36PM -0700, Jim Wilson wrote:
>   >> On Tue, 2004-04-20 at 22:57, H. J. Lu wrote: > This patch puts
>   >> libunwind.a in libgcc_s.so.1. The test result is at > We can do
>   >> it on ia64 since PIC is default on ia64.
> 
>   >> IA-64 code is PIC by default.  However, it is not true that
>   >> static library code and shared library code are the same.  There
>   >> are differences because of the IA-64 ABI, for instance, the rules
>   >> that say "own" data can be put in the small data section, but
>   >> what qualifies as "own" data is different for shared libraries
>   >> and static libraries.  This stuff is controlled by the -fpic

If the small data section is the only difference, we may get lucky
with libunwind.

>   >> option.  You must use -fpic for all code that goes into a shared
>   >> library.  Note: -fpic has always meant compile this code for
>   >> shared libraries, this is even true on systems like IA-64 where
>   >> code is PIC by default.  There is no guarantee that code in
>   >> libunwind.a was compiled with -fpic.  I don't see how this can
>   >> work.
> 
>   HJ> We can always require to compile the static libunwind library
>   HJ> with -fpic.
> 
> I really do not think this is the right approach.
> 

The ideal solution is to do what Solaris does. That is linker and
dynamic linker work together to support moving a definition from one
DSO to another, transparently. But it is not an option today.

Given that we should provide 100% backward binary compatibility, which
was the problem to begin with, our choices are very limited.


H.J.

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On Wed, 21 Apr 2004 09:34:17 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> The ideal solution is to do what Solaris does. That is linker
  HJ> and dynamic linker work together to support moving a definition
  HJ> from one DSO to another, transparently. But it is not an option
  HJ> today.

  HJ> Given that we should provide 100% backward binary compatibility,
  HJ> which was the problem to begin with, our choices are very
  HJ> limited.

No, the ideal solution is for GCC to be C++ ABI-compliant.

	--david

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[H. J. Lu]

On Wed, Apr 21, 2004 at 09:43:55AM -0700, David Mosberger wrote:
> >>>>> On Wed, 21 Apr 2004 09:34:17 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
>   HJ> The ideal solution is to do what Solaris does. That is linker
>   HJ> and dynamic linker work together to support moving a definition
>   HJ> from one DSO to another, transparently. But it is not an option
>   HJ> today.
> 
>   HJ> Given that we should provide 100% backward binary compatibility,
>   HJ> which was the problem to begin with, our choices are very
>   HJ> limited.
> 
> No, the ideal solution is for GCC to be C++ ABI-compliant.
> 

The unwinder in gcc is C++ ABI-compliant. But it doesn't mean you can
mix 2 unwind libraries together. As soon as you did

# g++ -shared ...

you may already have linked part of whatever unwind library gcc is
using into the resulting shared library. It won't be easy to use
another unwind library after that.

The whole problem started many years ago that we wanted to make sure
only one unwinder and one copy of its internal data structure are used
across executable and shared libraries it uses. The current scheme
is mostly OK on other platforms. But ia64 is an exception. Maybe we
should take another look at the problem.


H.J.

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[David Mosberger]

>>>>> On Wed, 21 Apr 2004 10:13:06 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> The unwinder in gcc is C++ ABI-compliant.

No, it isn't.  Not as long as it defines ABI-defined symbols as
versioned symbols.  That means anything that got linked against
libgcc_s will never be able to use the ABI-defined symbols from
another library (such as libunwind).

>>>>> On Wed, 21 Apr 2004 10:13:06 -0700, "H. J. Lu" <hjl@lucon.org> said:
  HJ> The unwinder in gcc is C++ ABI-compliant. But it doesn't mean
  HJ> you can mix 2 unwind libraries together. As soon as you did

  HJ> # g++ -shared ...

  HJ> you may already have linked part of whatever unwind library gcc
  HJ> is using into the resulting shared library. It won't be easy to
  HJ> use another unwind library after that.

Nonsense.  LD_PRELOAD=/usr/lib/libunwind.so would do just fine.

The problem isn't even libunwind-specific, as my example from
yesterday evening showed.

	--david

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[Jim Wilson]

On Wed, 2004-04-21 at 09:34, H. J. Lu wrote:
> If the small data section is the only difference, we may get lucky
> with libunwind.

It isn't the only difference, but it is probably the only one we have to
worry about.  I am pretty sure that thread local storage (TLS) works
differently in a shared library too, but I doubt that affects libunwind.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[Arnaud Charlet]

> 	* config/t-libunwind (LIB2ADDEH): Add $(srcdir)/gthr-gnat.c.

gthr-gnat.c is no longer needed on most platforms, and should be removed
rather than added (the only platform where it's still needed is OpenVMS).

Arno

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[H. J. Lu]

On Wed, Apr 21, 2004 at 09:04:00AM +0200, Arnaud Charlet wrote:
> > 	* config/t-libunwind (LIB2ADDEH): Add $(srcdir)/gthr-gnat.c.
> 
> gthr-gnat.c is no longer needed on most platforms, and should be removed
> rather than added (the only platform where it's still needed is OpenVMS).

Adding $(srcdir)/gthr-gnat.c seems to fix the Ada test hanging
problems. If it isn't needed, you can remove it for ia64 to see if it
introduces any problems for ia64.


H.J.

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[Arnaud Charlet]

> Adding $(srcdir)/gthr-gnat.c seems to fix the Ada test hanging
> problems. If it isn't needed, you can remove it for ia64 to see if it

I suspect a set up problem on your side.

> introduces any problems for ia64.

Sure, I simply don't have authority to remove these files without going
through a formal patch submission/approval, which is why I've never
bothered (up to now) doing it. It's somewhere on my todo list, but very
far away...

Arno

Removing gthr-gnat.c?

[H. J. Lu]

On Wed, Apr 21, 2004 at 04:43:23PM +0200, Arnaud Charlet wrote:
> > Adding $(srcdir)/gthr-gnat.c seems to fix the Ada test hanging
> > problems. If it isn't needed, you can remove it for ia64 to see if it
> 
> I suspect a set up problem on your side.
> 
> > introduces any problems for ia64.
> 
> Sure, I simply don't have authority to remove these files without going
> through a formal patch submission/approval, which is why I've never
> bothered (up to now) doing it. It's somewhere on my todo list, but very
> far away...
> 

That is very odd. gthr-gnat.c was added for Linux:

http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01720.html

Now, you are saying it is not needed.


H.J.

Re: Removing gthr-gnat.c?

[Arnaud Charlet]

> That is very odd. gthr-gnat.c was added for Linux:
> 
> http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01720.html
> 
> Now, you are saying it is not needed.

Nothing odd. I am saying that it is *no longer* needed.

Arno

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[Jim Wilson]

On Wed, 2004-04-21 at 07:33, H. J. Lu wrote:
> Adding $(srcdir)/gthr-gnat.c seems to fix the Ada test hanging
> problems. If it isn't needed, you can remove it for ia64 to see if it
> introduces any problems for ia64.

Looking at gthr-gnat.c, I see that it defines a __gnat_install_locks
function, and the only use is in gcc/ada/adaint.c inside VMS ifdefs.  So
apparently this file is not doing anything important for ia64-linux.

The question then is what does it do.  Well, it defines
gthread_mutex_{,un}lock functions that do nothing.  If you link with
these instead of the pthread versions, then obviously, you will never
run into pthread bugs because you aren't calling pthread locking
routines.  Also, just as obviously, multi-threaded programs that require
locking won't work anymore.  This seems like a potential problem to me.

There is another question of why we don't get link errors when we aren't
using gthr-gnat.c.  Where do the __gthread_mutex* functions come from in
that case?  I am puzzled.  I haven't tried doing builds and looking at
them to see what is going on.

On the other hand, gnat-gthr.c is there for apparently all other
targets, so it probably should be there, even if it seems to be flawed. 
At least it means ia64-linux has the same flaw as every other target
instead of having a different set of flaws.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[Arnaud Charlet]

> Looking at gthr-gnat.c, I see that it defines a __gnat_install_locks
> function, and the only use is in gcc/ada/adaint.c inside VMS ifdefs.  So
> apparently this file is not doing anything important for ia64-linux.

gthr-gnat.c is no longer needed at all, except on VMS.

> The question then is what does it do.  Well, it defines
> gthread_mutex_{,un}lock functions that do nothing.  If you link with
> these instead of the pthread versions, then obviously, you will never
> run into pthread bugs because you aren't calling pthread locking
> routines.  Also, just as obviously, multi-threaded programs that require
> locking won't work anymore.  This seems like a potential problem to me.

No, you missed the fact that gthr-gnat.c is using pointers to functions,
and provides a gnat_install_locks, which is called with appropriate
locking routines by the GNAT tasking run time when tasking is used.

> There is another question of why we don't get link errors when we aren't
> using gthr-gnat.c.  Where do the __gthread_mutex* functions come from in
> that case?  I am puzzled.  I haven't tried doing builds and looking at
> them to see what is going on.

Because no file is referencing these symbols.

> On the other hand, gnat-gthr.c is there for apparently all other
> targets, so it probably should be there, even if it seems to be flawed. 

No, gthr-gnat.c should only be there at this point for VMS. It would be
removed for all other targets, not added.

Arno

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[Jim Wilson]

I find this message to be very puzzling.  The only way I can interpret
it is as an insult.  However, I am trying to help you by investigating
and solving an Ada related problem.  You should not be insulting someone
who is trying to help you.  Maybe there is a language related issue
here, or maybe you are venting general frustrations or something, or
maybe you don't understand what I am trying to accomplish here.

By the way, what I am trying to do here is reconcile differing
statements made by you and HJ.  Your statements conflict.  Repeating the
conflicting statements does not solve anything.  What we need is to
investigate the issues without preconceptions, and without taking
sides.  That is what I am trying to do.  Since, I have mostly confirmed
that your statements are correct, I can't understand why you are
responding to me this way.

On Fri, 2004-04-23 at 00:07, Arnaud Charlet wrote:
> gthr-gnat.c is no longer needed at all, except on VMS.

I know.  You said that in an earlier message, and I agreed with you.  So
why are restating the obvious?  That could be misconstrued as an insult.

> No, you missed the fact that gthr-gnat.c is using pointers to functions,

You are mistaken.  I did not miss this fact.  The only way I could have
missed this fact is if I was incompetent, and I am not incompetent.

If you had asked if maybe possibly I had accidentally missed something
obvious, then that would have been OK.  I am human, and I do make
mistakes.  But to state as a fact that I missed something obvious is to
make a strong implication that I am incompetent, and hence the only way
I can interpret the above statement is as an insult.  I am offended by
it, and hope that you do not make this mistake again.

> Because no file is referencing these symbols.

Do you know this for a fact?  Or are you making an logical assumption? 
If you are making a logical assumption, then I would agree with you. 
However, statements from HJ contradict this.  It is possible that there
is some obscure subtle interaction that is IA-64 specific and which has
gone unnoticed so far.  Since I am trying to keep an open mind, I must
admit that this is a possibility however remote.  It is also possible
that HJ made a mistake.  The only way to be sure if to perform an
experiment.  That is what I am doing.  Performing an experiment to
verify the facts.  It is the right thing to do in this case.

> No, gthr-gnat.c should only be there at this point for VMS. It would be
> removed for all other targets, not added.

You are confusing issues here.  That gthr-gnat.c should only be there
for VMS is true.  However, if you look at the sources, you can clearly
see that it is there for all targets except ia64-linux.  Therefore, we
have an obvious problem, because ia64-linux is different from other
targets when it should not be.  This needs to be investigated.  That is
what I am doing.  Even if it is wrong for ia64-linux to use gthr-gnat.c,
it might be necessary to add it to resolve this inconsistency.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[Arnaud Charlet]

OK, let's all be constructive as you were in your last message.

First of all, I deeply apologize if you felt I was insulting you: I
was not and never intended to.

Now for some of the details:

> > gthr-gnat.c is no longer needed at all, except on VMS.
> 
> I know.  You said that in an earlier message, and I agreed with you.  So
> why are restating the obvious?  That could be misconstrued as an insult.

It certainly is not. I have no way of knowing whether you indeed saw my
earlier message, whether this message was phrased in a way that could be
understood as intended by others, etc...

You know that you understood my message, I didn't, so I had to assume the
default, which is that it doesn't hurt to repeat an information twice
(this is what all teachers do btw, and students do not find that their
teachers insult them when teachers repeat things twice).

> > No, you missed the fact that gthr-gnat.c is using pointers to functions,
> 
> You are mistaken.  I did not miss this fact.  The only way I could have
> missed this fact is if I was incompetent, and I am not incompetent.

I certainly did not want to imply that you are incompetent.

It's a communication problem: your message as I read it seemed to imply that
you had not seen the whole usage of this feature, which even if true
would not mean you are incompetent. It would simply mean that you missed
it because e.g. you were looking at a part of the code that you are
not familiar with (the Ada front-end), and that the code is mixed/used
between Ada and C in various places.

And also, I was more responding for others than you, since your message
itself was a response, and since I understood it differently than you
phrased it, other people may have done exactly the same thing. So I
believe my clarification and additional information on your statement was
helpful to others. I'm sure you can understand that and would agree with
that.

> I can interpret the above statement is as an insult.  I am offended by
> it, and hope that you do not make this mistake again.

With all your respect, I believe that if you interpret the above statement
as an insult, it could be because indeed you know too well that you are
competent, and cannot accept remarks/suggestions/help from others as
openly as someone less competent (or simply someone not as focused on the fact
that he is competent). You also seemed to miss the fact that not everyone knows
you personally and not everyone knows your level of knowledge and knows
that you read all messages on this list and always interpret them as initially
intended.

On my side, I agree that I should not have assumed anything, and phrase my
answer differently. This would probably have avoided this whole discussion.
I'll try to remember that in the future and be more careful in my answers.

Now, starting to know better your personality, there are some chances (and
hopefully I will be proven wrong) that you take the above paragraphs as an
insult: it's not, I'm trying to be helpful and help you realize that there
are many ways to communicate and state things, and that on a public list with
people coming from different background, it's impossible to know everyone and
to respond to everyone with exactly the phrasing that will make them understand
what you meant to say. And even if it were possible, other people may still
misinterpret some statements.

This thread is a very good example: you did not use the right phrasing to
allow me to understand what you were saying (although your phrasing was
certainly obvious to you), and I did not use the right phrasing to answer
to you either.

> > Because no file is referencing these symbols.

> Do you know this for a fact?  Or are you making an logical assumption? 
> If you are making a logical assumption, then I would agree with you. 
> However, statements from HJ contradict this.  It is possible that there

It's more than a logical assumption. If the code were indeed referenced,
we would get undefined references when linking.

> is some obscure subtle interaction that is IA-64 specific and which has
> gone unnoticed so far.  Since I am trying to keep an open mind, I must
> admit that this is a possibility however remote.  It is also possible

Right, it could be.

So I'd suggest the following experiment: remove all traces of gthr-gnat.c
in the GCC sources in a local copy and see whether you get some undefined
references and some changes in behavior.

If removing all traces still allows you to link, then it indeed proves that
this file is not needed.

BTW, the above suggestion was 'obvious' to me after my previous messages,
and I assumed that others (e.g. you) would do/understand it without having to
explicitely state it. Clearly, that was either a mistake on my part
(assuming other people would have the same way of reasoning than myself),
or indeed you understood that from my previous messages as I assumed it,
and since you didn't state it explicitely, I decided to make it explicit.

Following your reasoning, if indeed you already understood and maybe made
the above experiment, you might also find 'insulting' that I made this
suggestion explicit, since it was 'obvious' to you what I had in mind,
because you are <choose your word here: competent, etc...>.

All right, back to technical matters, and waiting to see the result of
the above experiment if anyone finds it's a helpful suggestion and has
the time to do it.

Arno

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[Jim Wilson]

On Sat, 2004-04-24 at 04:24, Arnaud Charlet wrote:
> Now for some of the details:

Thanks for the info.  It was helpful.  I misunderstood the intent of
your earlier message.

I did a build over the weekend to try to reproduce HJ's result and came
up empty.  Adding gthr-gnat.c to LIB2ADDEH had no effect on the
ia64-linux Ada testsuite results, which is what I expected from my
analysis and from your analysis.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols

[Arnaud Charlet]

> Thanks for the info.  It was helpful.  I misunderstood the intent of
> your earlier message.

No problem. I know my messages are usually a little bit too much 'to the point'
and sometimes lack additional info/context. I'll try to improve that in the
future.

> I did a build over the weekend to try to reproduce HJ's result and came
> up empty.  Adding gthr-gnat.c to LIB2ADDEH had no effect on the
> ia64-linux Ada testsuite results, which is what I expected from my
> analysis and from your analysis.

OK, that confirms indeed the analysis made so far.

Now, we would need to find what in HJ's set up is different.
Like, what configure options are used, what bootstrap options are used,
what sources, and whether there are local changes in his tree.

Arno