This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/17266] New: Always defining __extern_always_inline may generate infinite recursion
- From: "siddhesh at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 14 Aug 2014 00:34:29 +0000
- Subject: [Bug libc/17266] New: Always defining __extern_always_inline may generate infinite recursion
- Auto-submitted: auto-generated
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.