versioning of _Unwind_*() symbols

H. J. Lu hjl@lucon.org
Thu Apr 22 18:54:00 GMT 2004


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.



More information about the Gcc mailing list