[Bug libc/17573] stpcpy / mempcpy namespace

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

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.