This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCH 2/2] Remove ancient GCC string inlines
- From: "Wilco Dijkstra" <wdijkstr at arm dot com>
- To: "'Joseph Myers'" <joseph at codesourcery dot com>
- Cc: "'GNU C Library'" <libc-alpha at sourceware dot org>
- Date: Tue, 13 Oct 2015 17:33:39 +0100
- Subject: RE: [PATCH 2/2] Remove ancient GCC string inlines
- Authentication-results: sourceware.org; auth=none
- References: <000401d102aa$8db859e0$a9290da0$ at com> <alpine dot DEB dot 2 dot 10 dot 1510091558180 dot 20476 at digraph dot polyomino dot org dot uk> <000801d102b1$3e4f33e0$baed9ba0$ at com> <alpine dot DEB dot 2 dot 10 dot 1510091657190 dot 20476 at digraph dot polyomino dot org dot uk> <000901d104e0$069f65b0$13de3110$ at com> <alpine dot DEB dot 2 dot 10 dot 1510121131000 dot 16894 at digraph dot polyomino dot org dot uk> <000a01d104ed$0b7a9c00$226fd400$ at com> <alpine dot DEB dot 2 dot 10 dot 1510121256230 dot 30255 at digraph dot polyomino dot org dot uk> <000b01d10518$befeab10$3cfc0130$ at com> <alpine dot DEB dot 2 dot 10 dot 1510121809310 dot 6267 at digraph dot polyomino dot org dot uk> <000f01d105c9$02839c00$078ad400$ at com> <alpine dot DEB dot 2 dot 10 dot 1510131512140 dot 10084 at digraph dot polyomino dot org dot uk>
> Joseph Myers wrote:
> 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.
Correct. The out-of-line copies of the inlines have an ABI that changes with
the _STRING_ARCH_unaligned setting, so they should use a different define
that cannot be changed after the initial GLIBC version for a new target.
> 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).
A quick search in the ChangeLog/git log doesn't show up any recent changes.
Changing it for AArch64 is safe as there isn't an old enough compiler that
could have generated out of line copies of these inline functions.
> 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>).
That looks like an actual ABI incompatibility that we cannot fix
(68000 binaries may not work with a GLIBC built for 68020).
Wilco