[Bug libc/17266] New: Always defining __extern_always_inline may generate infinite recursion

[Bug libc/17266] New: Always defining __extern_always_inline may generate infinite recursion

[siddhesh at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17266

            Bug ID: 17266
           Summary: Always defining __extern_always_inline may generate
                    infinite recursion
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: siddhesh at redhat dot com
          Reporter: siddhesh at redhat dot com
                CC: drepper.fsp at gmail dot com

The fix for bug 14530 and bug 13741 cause a regression that may cause older
compilers to generate infinite recursion for wrapper functions that rely on GNU
extern inline semantics of newer compiler versions, i.e. g++4.3 and later.

Consider say:

#include <wchar.h>

volatile int i = ' ';
wint_t (*fn) (int) = btowc;

int
main ()
{
  asm ("");
  i = fn (i);
  return 0;
}

When this is compiled e.g. with g++ 3.2, because of the incorrect
BZ #14530, #13741 fix, the program will recurse endlessly.
That is because g++ < 4.3 only provided the C++ inline semantics, not
gnu_inline, but when glibc headers use __extern_inline,
__extern_always_inline or __fortify_function, they rely on GNU extern inline
semantics.  The C++ inline semantics when btowc can't be inlined is
that the compiler emits a comdat out of line, but btowc is:
extern wint_t __btowc_alias (int __c) __asm ("btowc");

__extern_inline wint_t
__NTH (btowc (int __c))
{ return (__builtin_constant_p (__c) && __c >= '\0' && __c <= '\x7f'
          ? (wint_t) __c : __btowc_alias (__c)); }

When the compiler emits out of line copy of this, it will be e.g. on
i?86/x86_64 .globl btowc; btowc: jmp btowc;
Similarly with any other __extern_*inline functions in glibc headers that
sometimes call the original function through aliases.
One can get the problematic definitions out of line even with
-fkeep-inline-functions and similar.

The code before these fixes was the most reliable way to handle this, so the
above bugs ought to be fixed in a different manner.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17266] Always defining __extern_always_inline may generate infinite recursion

[jakub at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17266

Jakub Jelinek <jakub at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat dot com

--- Comment #1 from Jakub Jelinek <jakub at redhat dot com> ---
Note this bug has been already fixed once:
https://sourceware.org/ml/libc-hacker/2006-03/msg00042.html
but the #ifndef __cplusplus has been later on replaced with guards that
__extern_inline is defined (or is that __USE_EXTERN_INLINES?).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17266] Always defining __extern_always_inline may generate infinite recursion

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17266

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
It has been undone by
<http://sourceware.org/ml/glibc-cvs/2007-q3/msg00912.html>.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17266] Always defining __extern_always_inline may generate infinite recursion

[jakub at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17266

--- Comment #3 from Jakub Jelinek <jakub at redhat dot com> ---
Sure.  But at that time
__extern_inline/__extern_always_inline/__USE_EXTERN_INLINES weren't defined for
C++ with old g++ compilers, so Uli's change was just fine.
Which is the state that Siddhesh is trying to restore.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17266] Always defining __extern_always_inline may generate infinite recursion

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17266

--- Comment #4 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  884ddc5081278f488ef8cd49951f41cfdbb480ce (commit)
      from  a7b872687073decdcc7effc2289877d69058aca9 (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=884ddc5081278f488ef8cd49951f41cfdbb480ce

commit 884ddc5081278f488ef8cd49951f41cfdbb480ce
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Tue Sep 16 14:08:48 2014 +0530

    Revert to defining __extern_inline only for gcc-4.3+ (BZ #17266)

    The check for only __GNUC_STDC_INLINE__ and __GNUC_GNU_INLINE__ may
    not be sufficient since those flags were added during initial support
    for C99 inlining semantics.  There is also a problem with always
    defining __extern_inline and __extern_always_inline, since it enables
    inline wrapper functions even when GNU inlining semantics are not
    guaranteed.  This, along with the possibility of such wrappers using
    redirection (btowc for example) could result in compiler generating an
    infinitely recusrive call to the function.

    In fact it was such a recursion that led to this code being written
    the way it was; see:

    https://bugzilla.redhat.com/show_bug.cgi?id=186410

    The initial change was to fix bugs 14530 and 13741, but they can be
    resolved by checking if __fortify_function and/or
    __extern_always_inline are defined, as it has been done in this patch.
    In addition, I have audited uses of __extern_always_inline to make
    sure that none of the uses result in compilation errors.

    There is however a regression in this patch for llvm, since it reverts
    the llvm expectation that __GNUC_STDC_INLINE__ or __GNUC_GNU_INLINE__
    definition imply proper extern inline semantics.

    2014-09-16  Siddhesh Poyarekar  <siddhesh@redhat.com>
            Jakub Jelinek  <jakub@redhat.com>

        [BZ #17266]
        * libio/stdio.h: Check definition of __fortify_function
        instead of __extern_always_inline to include bits/stdio2.h.
        * math/bits/math-finite.h [__USE_XOPEN || __USE_ISOC99]: Also
        check if __extern_always_inline is defined.
        [__USE_MISC || __USE_XOPEN]: Likewise.
        [__USE_ISOC99] Likewise.
        * misc/sys/cdefs.h (__fortify_function): Define only if
        __extern_always_inline is defined.
        [!__cplusplus || __GNUC_PREREQ (4,3)]: Revert to defining
        __extern_always_inline and __extern_inline only for g++-4.3
        and newer or a compatible gcc.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog               |   16 ++++++++++++++++
 libio/stdio.h           |    2 +-
 math/bits/math-finite.h |    8 +++++---
 misc/sys/cdefs.h        |   21 +++++++++++----------
 4 files changed, 33 insertions(+), 14 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17266] Always defining __extern_always_inline may generate infinite recursion

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17266

--- Comment #5 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, release/2.20/master has been updated
       via  979add9f87577c10c629af82586e48b686672134 (commit)
      from  ea5509237291f1a109d46052353ece197f4213bc (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=979add9f87577c10c629af82586e48b686672134

commit 979add9f87577c10c629af82586e48b686672134
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Tue Sep 16 14:14:11 2014 +0530

    Revert to defining __extern_inline only for gcc-4.3+ (BZ #17266)

    The check for only __GNUC_STDC_INLINE__ and __GNUC_GNU_INLINE__ may
    not be sufficient since those flags were added during initial support
    for C99 inlining semantics.  There is also a problem with always
    defining __extern_inline and __extern_always_inline, since it enables
    inline wrapper functions even when GNU inlining semantics are not
    guaranteed.  This, along with the possibility of such wrappers using
    redirection (btowc for example) could result in compiler generating an
    infinitely recusrive call to the function.

    In fact it was such a recursion that led to this code being written
    the way it was; see:

    https://bugzilla.redhat.com/show_bug.cgi?id=186410

    The initial change was to fix bugs 14530 and 13741, but they can be
    resolved by checking if __fortify_function and/or
    __extern_always_inline are defined, as it has been done in this patch.
    In addition, I have audited uses of __extern_always_inline to make
    sure that none of the uses result in compilation errors.

    There is however a regression in this patch for llvm, since it reverts
    the llvm expectation that __GNUC_STDC_INLINE__ or __GNUC_GNU_INLINE__
    definition imply proper extern inline semantics.

    2014-09-16  Siddhesh Poyarekar  <siddhesh@redhat.com>
            Jakub Jelinek  <jakub@redhat.com>

        [BZ #17266]
        * libio/stdio.h: Check definition of __fortify_function
        instead of __extern_always_inline to include bits/stdio2.h.
        * math/bits/math-finite.h [__USE_XOPEN || __USE_ISOC99]: Also
        check if __extern_always_inline is defined.
        [__USE_MISC || __USE_XOPEN]: Likewise.
        [__USE_ISOC99] Likewise.
        * misc/sys/cdefs.h (__fortify_function): Define only if
        __extern_always_inline is defined.
        [!__cplusplus || __GNUC_PREREQ (4,3)]: Revert to defining
        __extern_always_inline and __extern_inline only for g++-4.3
        and newer or a compatible gcc.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog               |   16 ++++++++++++++++
 NEWS                    |    2 +-
 libio/stdio.h           |    2 +-
 math/bits/math-finite.h |    8 +++++---
 misc/sys/cdefs.h        |   21 +++++++++++----------
 5 files changed, 34 insertions(+), 15 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17266] Always defining __extern_always_inline may generate infinite recursion

[siddhesh at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17266

Siddhesh Poyarekar <siddhesh at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Siddhesh Poyarekar <siddhesh at redhat dot com> ---
Fixed in master and 2.20.1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17266] Always defining __extern_always_inline may generate infinite recursion

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17266

--- Comment #7 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  d330b980e9ee2349492087a279a9c7bf294f6b47 (commit)
       via  02657da2cf4457804ed938ee08b8316249126444 (commit)
       via  653b1080fad02725ab66e504a7bfeecf4347d7aa (commit)
       via  602f80ec8b966cfad3b61914cbe14ee606cedf6e (commit)
      from  545583d664b64ff234b99aca0d85e99c8a55808f (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=d330b980e9ee2349492087a279a9c7bf294f6b47

commit d330b980e9ee2349492087a279a9c7bf294f6b47
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Tue Sep 16 22:20:45 2014 +0530

    Remove CFLAGS for interp.c

    Replace it with including an auto-generated linker-runtime.h.
    Build-tested on x86_64 and found that there was no change in the
    generated code.

        * elf/Makefile (CFLAGS-interp.c): Remove.
        ($(elf-objpfx)runtime-linker.h): Generate header with linker
        path string.
        * elf/interp.c: Include generated runtime-linker.h

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=02657da2cf4457804ed938ee08b8316249126444

commit 02657da2cf4457804ed938ee08b8316249126444
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Tue Sep 16 22:19:22 2014 +0530

    Include .interp section only for libc.so

    Barring libc.so and libdl.so, none of the libraries have any entry
    points, so it is pointless to add a .interp section for them.  The
    libdl.so entry point (in dlfcn/eval.c) is also defunct, so remove that
    file as well.

    Build tested for x86_64, ppc64 and s390x.  I have not moved
    CFLAGS-interp.c to CPPFLAGS-interp.c isnce I'll be removing it
    completely in a follow-up patch.

    Siddhesh

        * Makerules (lib%.so): Don't include $(+interp) in
        prerequisites.
        * elf/Makefile (CFLAGS-interp.c): Don't define NOT_IN_libc.
        * dlfcn/eval.c: Remove file.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=653b1080fad02725ab66e504a7bfeecf4347d7aa

commit 653b1080fad02725ab66e504a7bfeecf4347d7aa
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Tue Sep 16 22:18:20 2014 +0530

    Assume that all _[PS]C_* and _CS_* macros are always defined

    The macros in question are always defined in confname.h for all
    variants and there seems to be no reason to allow such variants to
    exist anyway.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=602f80ec8b966cfad3b61914cbe14ee606cedf6e

commit 602f80ec8b966cfad3b61914cbe14ee606cedf6e
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Tue Sep 16 22:16:01 2014 +0530

    Make __extern_always_inline usable on clang++ again

    The fix for BZ #17266 (884ddc5081278f488ef8cd49951f41cfdbb480ce)
    removed changes that had gone into cdefs.h to make
    __extern_always_inline usable with clang++.  This patch adds back
    support for clang to detect if GNU inlining semantics are available,
    this time without breaking the gcc use case.  The check put here is
    based on the earlier patch and assertion[1] that checking if
    __GNUC_STDC_INLINE__ or __GNUC_GNU_INLINE__ is defined is sufficient
    to determine that clang++ suports GNU inlining semantics.

    Tested with a simple program that builds with __extern_always_inline
    with the patch and fails compilation without it.

     #include <stdio.h>
     #include <sys/cdefs.h>

    extern void foo_alias (void) __asm ("foo");

    __extern_always_inline void
    foo (void)
    {
      puts ("hi oh world!");
      return foo_alias ();
    }

    void
    foo_alias (void)
    {
      puts ("hell oh world");
    }

    int
    main ()
    {
      foo ();
    }

    [1] https://sourceware.org/ml/libc-alpha/2012-12/msg00306.html

        [BZ #17266]
        * misc/sys/cdefs.h: Define __extern_always_inline for clang
        4.2 and newer.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog        |   17 ++
 Makerules        |    2 +-
 dlfcn/eval.c     |  200 -----------------
 elf/Makefile     |   14 +-
 elf/interp.c     |    2 +
 misc/sys/cdefs.h |   10 +-
 posix/getconf.c  |  628 ------------------------------------------------------
 7 files changed, 38 insertions(+), 835 deletions(-)
 delete mode 100644 dlfcn/eval.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.