This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] libio: use PTR_MANGLE/PTR_DEMANGLE for FILE vtables
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Kees Cook <keescook at chromium dot org>, libc-alpha <libc-alpha at sourceware dot org>, Mike Frysinger <vapier at gentoo dot org>, Adam Conrad <adconrad at 0c3 dot net>
- Date: Thu, 15 Oct 2015 15:56:00 +0000
- Subject: Re: [PATCH v2] libio: use PTR_MANGLE/PTR_DEMANGLE for FILE vtables
- Authentication-results: sourceware.org; auth=none
- References: <20151001184048 dot GA31563 at www dot outflux dot net> <560D8108 dot 6060802 at redhat dot com> <CAGXu5jLi7iW+543YD7ySDb7Yq+_2SfGW8q3z50p4C3Usg5dC0w at mail dot gmail dot com> <560D8A2F dot 8020900 at redhat dot com> <CAGXu5jLCBUKaXoX3Dy1dcEc9bd0WcXAZU32zOaEHXechEfNuxg at mail dot gmail dot com> <560D943C dot 40301 at redhat dot com> <CAGXu5jKNssVif3=JsufU0a_tQpcURVgdDjDdHUkRmY1PQdv7LQ at mail dot gmail dot com> <561FA2CA dot 1050309 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1510151523160 dot 32402 at digraph dot polyomino dot org dot uk> <561FC841 dot 8060401 at redhat dot com>
On Thu, 15 Oct 2015, Florian Weimer wrote:
> > Would that still keep working (a) C++ binaries, whether using shared or
> > static libstdc++, built with any official GCC release supporting glibc2,
> > where those binaries did not pass C++ classes to C interfaces,
>
> No, they would no longer work.
Well, I think the starting point is that those are valid binaries that
users who've kept their binaries and libstdc++.so shared libraries should
be able to expect to continue to work - that we don't break binary
compatibility for users using documented interfaces in the documented way.
We have symbol versioning for backwards compatibility with binaries built
with glibc 2.0. Is it not possible to do something like that for
compatibility with these C++ binaries (if necessary, increasing the value
of _G_IO_IO_FILE_VERSION / _IO_stdin_used again)?
(I don't know how much compatibility the existing versioning provides if
the executable and shared libraries mix binaries built with 2.0 and
binaries built with >= 2.1. If we introduce new versions I suppose we'd
want mixtures of pre- and post-2.23 executables and shared libraries to
work as long as they don't have any code using old libstdc++, but the old
libstdc++ case could probably be limited to having the executable and all
the non-glibc shared libraries it uses built with old glibc. And
architectures not supported before GCC 3.0 wouldn't need the compatibility
code.)
> > (I'm not concerned with binaries built with non-default configurations of
> > GCC 3.0 or later, which restricts compatibility concerns to architectures
> > supported in 2.95 with ABIs still supported in glibc. I think that means
> > alpha, i386 32-bit, m68k, mips 32-bit, powerpc 32-bit, sparc 32-bit and
> > 64-bit.)
>
> We have libstdc++ compat libraries for ia64, s390 and s390x, too.
Is that about 2.96 or backported architecture support (since 2.95.3
doesn't have ports to those architectures at all)?
--
Joseph S. Myers
joseph@codesourcery.com