[PATCH v2] libio: use PTR_MANGLE/PTR_DEMANGLE for FILE vtables

[Joseph Myers]

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