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

[Florian Weimer <fweimer at redhat dot com>]

On 10/15/2015 05:56 PM, Joseph Myers wrote:
> 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.

I respect your view, but we did that for errno (and presumably _res and
h_errno, but I have less experience with that) and the i386 ABI bump for
SSE stack alignment.

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

If we can detect that a binary references these symbols:

_IO_file_init@GLIBC_2.1
_IO_init@GLIBC_2.0
_IO_str_init_readonly@GLIBC_2.0
_IO_str_init_static@GLIBC_2.0

we can disable vtable hardening globally.  This would not cover the
scenario where the binary dlopens something that uses an old libstdc++
(linked statically or dynamically) later, but it would provide
compatibility where a copy of libstdc++ is pulled in through DT_NEEDED.

This will not enable us to do substantial implementation changes in
libio because we would still be committed to the tight coupling with old
libstdc++, and we would have to keep maintaining two code paths
indefinitely (one of which is impossible to test without a historic
toolchain).

Bumping symbol versions for stdio functions would cause significant pain
for distributions which do not do mass rebuilds because FILE * streams
are often passed across library boundaries.

>>> (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)?

ia64 seems to be 2.96, s390 and s390x are 2.95.

Florian