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