From: Joseph Myers <joseph@codesourcery.com>
To: Wilco Dijkstra <wdijkstr@arm.com>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: RE: [PATCH 2/2] Remove ancient GCC string inlines
Date: Tue, 13 Oct 2015 15:21:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.10.1510131512140.10084@digraph.polyomino.org.uk> (raw)
In-Reply-To: <000f01d105c9$02839c00$078ad400$@com>
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
next prev parent reply other threads:[~2015-10-13 15:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-09 15:53 Wilco Dijkstra
2015-10-09 16:01 ` Joseph Myers
2015-10-09 16:40 ` Wilco Dijkstra
2015-10-09 17:01 ` Joseph Myers
2015-10-12 11:20 ` Wilco Dijkstra
2015-10-12 11:33 ` Joseph Myers
2015-10-12 12:54 ` Wilco Dijkstra
2015-10-12 13:00 ` Joseph Myers
2015-10-12 18:06 ` Wilco Dijkstra
2015-10-12 18:10 ` Joseph Myers
2015-10-13 15:08 ` Wilco Dijkstra
2015-10-13 15:21 ` Joseph Myers [this message]
2015-10-13 16:33 ` Wilco Dijkstra
2015-10-13 17:34 ` Andreas Schwab
2015-10-13 17:29 ` Joseph Myers
2015-10-09 17:07 ` Joseph Myers
[not found] <FF1B652685AE434E94C2981B001E196529AF7B0DBC@GEORGE.Emea.Arm.com>
2015-12-16 13:08 ` Wilco Dijkstra
2015-12-16 18:38 ` Joseph Myers
2015-12-17 13:48 ` Wilco Dijkstra
2015-12-17 20:33 ` Joseph Myers
2015-12-17 22:59 ` Wilco Dijkstra
2016-02-19 17:20 Wilco Dijkstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.10.1510131512140.10084@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=wdijkstr@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).