Fix stpcpy / mempcpy namespace (bug 17573).

Various glibc functions call __stpcpy and __mempcpy for namespace
reasons instead of plain stpcpy and mempcpy.  But __stpcpy and
__mempcpy are macros that call __builtin_stpcpy and __builtin_mempcpy,
and unless GCC optimizes the calls, they end up calling the C
functions stpcpy and mempcpy.

For calls from within shared libc, libc_hidden_builtin_proto ensures
that calls to those C functions are in turn mapped to call __GI_stpcpy
and __GI_mempcpy.  However, for static libc, and for calls from shared
libraries other than libc, the ELF symbols stpcpy and mempcpy end up
getting called, breaking the ISO C namespace (in the case of stpcpy)
or glibc conventions about not relying on the "future library
directions" reservations (in the case of mempcpy).

This patch fixes this by adding declarations of these functions to
include/string.h, under an appropriate condition, with __asm__ used to
change the assembler name used for calls (the mempcpy case was
previously discussed, and the approach for the fix is as I suggested
in <https://sourceware.org/ml/libc-alpha/2013-02/msg00063.html>).

Tested for x86_64 with the testsuite; also checked that dcigettext.o
(an example previously noted of undesired calls to stpcpy and mempcpy)
now calls __stpcpy and __mempcpy instead, as do non-libc shared
libraries (__stpcpy and __mempcpy were already exported from shared
libc).  Disassembly of installed shared libraries isn't easy to
compare because of reordered PLT entries resulting from the change in
functions called (libnsl, libnss_compat, libnss_dns, libnss_files,
libnss_hesiod, libnss_nis, libnss_nisplus, libpthread, librt all have
such changes).

	[BZ #17573]
	* include/string.h [NOT_IN_libc || !SHARED] (mempcpy): Declare
	with asm name __mempcpy.
	[NOT_IN_libc || !SHARED] (stpcpy): Declare with asm name __stpcpy.

0 files changed, 0 insertions, 0 deletions