[PATCH 2/2] Remove ancient GCC string inlines

[Joseph Myers]

On Tue, 13 Oct 2015, Wilco Dijkstra wrote:

> It does indeed. It also ensures that future changes of 
> _STRING_ARCH_unaligned no longer cause backwards compatibility issues 
> due to the inline functions using different ABIs depending on the 
> _STRING_ARCH_unaligned setting (I didn't find a BZ entry for this one).

Please explain further.  ABI issues should only ever apply for out-of-line 
copies of inline functions, and we need to support old executables and 
shared libraries (as opposed to old .o / .a files) indefinitely.

Thus, if _STRING_ARCH_unaligned affects the ABI for any of the functions 
moved out of line, we need to ensure that they are built with the ABI 
applicable for the glibc versions in which the inlines were present, not 
one relating to a future different definition of _STRING_ARCH_unaligned.  
If changes to _STRING_ARCH_unaligned are contemplated, we may need to have 
a separate ABI macro for use only for building these out-of-line 
functions.  And we need to understand whether any architecture has changed 
its definition of _STRING_ARCH_unaligned during the lifetime of these 
inlines, so that we can determine the most compatible definition of the 
new macro for such an architecture (probably the one contemporary with GCC 
versions for which these inlines were relevant, rather than any more 
recent optimized value of that macro).

One issue of concern would be that 
sysdeps/m68k/m680x0/m68020/bits/string.h defines _STRING_ARCH_unaligned to 
1, but the ABI isn't meant to differ depending on whether the m68020/ 
directory is or is not used (there's only one classic m68k ABI listed at 
<https://sourceware.org/glibc/wiki/ABIList>).

-- 
Joseph S. Myers
joseph@codesourcery.com