* [Bug libc/17573] stpcpy / mempcpy namespace
2014-11-10 16:10 [Bug libc/17573] New: stpcpy / mempcpy namespace jsm28 at gcc dot gnu.org
@ 2014-11-12 22:38 ` cvs-commit at gcc dot gnu.org
2014-11-12 22:51 ` jsm28 at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-11-12 22:38 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17573
--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".
The branch, master has been updated
via 939da41143341bbcdd3dd50ee7b57776603da260 (commit)
from 293d9a41805b1eeb440a2c59a717b332cd9c2384 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=939da41143341bbcdd3dd50ee7b57776603da260
commit 939da41143341bbcdd3dd50ee7b57776603da260
Author: Joseph Myers <joseph@codesourcery.com>
Date: Wed Nov 12 22:36:34 2014 +0000
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.
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 5 +++++
NEWS | 2 +-
include/string.h | 7 +++++++
3 files changed, 13 insertions(+), 1 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread