From: Nick Desaulniers <ndesaulniers@google.com>
To: akpm@linux-foundation.org, hpa@zytor.com, mingo@redhat.com,
tglx@linutronix.de
Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, virtualization@lists.linux-foundation.org,
astrachan@google.com, manojgupta@google.com,
ghackmann@google.com, sedat.dilek@gmail.com, tstellar@redhat.com,
keescook@google.com, yamada.masahiro@socionext.com,
michal.lkml@markovi.net, linux-kbuild@vger.kernel.org,
geert@linux-m68k.org, will.deacon@arm.com,
mawilcox@microsoft.com, arnd@arndb.de, rientjes@google.com,
acme@redhat.com, pombredanne@nexb.com, aryabinin@virtuozzo.com,
kstewart@linuxfoundation.org, boris.ostrovsky@oracle.com,
jan.kiszka@siemens.com, rostedt@goodmis.org,
kirill.shutemov@linux.intel.com, ard.biesheuvel@linaro.org,
akataria@vmware.com, brijesh.singh@amd.com,
caoj.fnst@cn.fujitsu.com, gregkh@linuxfoundation.org,
jarkko.sakkinen@linux.intel.com, jgross@suse.com,
jpoimboe@redhat.com, mka@chromium.org, ndesaulniers@google.com,
thomas.lendacky@amd.com, tweek@google.com, mjg59@google.com,
joe@perches.com, andrea.parri@amarulasolutions.com
Subject: [PATCH v5 1/3] compiler-gcc.h: add gnu_inline to all inline declarations
Date: Wed, 13 Jun 2018 14:05:16 -0700 [thread overview]
Message-ID: <20180613210518.113983-2-ndesaulniers@google.com> (raw)
In-Reply-To: <20180613210518.113983-1-ndesaulniers@google.com>
Functions marked extern inline do not emit an externally visible
function when the gnu89 C standard is used. Some KBUILD Makefiles
overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without
an explicit C standard specified, the default is gnu11. Since c99, the
semantics of extern inline have changed such that an externally visible
function is always emitted. This can lead to multiple definition errors
of extern inline functions at link time of compilation units whose build
files have removed an explicit C standard compiler flag for users of GCC
5.1+ or Clang.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: H. Peter Anvin <hpa@zytor.com>
Suggested-by: Joe Perches <joe@perches.com>
---
include/linux/compiler-gcc.h | 29 ++++++++++++++++++++++-------
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index b4bf73f5e38f..c7cfca4ba02b 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -65,6 +65,18 @@
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
#endif
+/*
+ * Feature detection for gnu_inline (gnu89 extern inline semantics). Either
+ * __GNUC_STDC_INLINE__ is defined (not using gnu89 extern inline semantics,
+ * and we opt in to the gnu89 semantics), or __GNUC_STDC_INLINE__ is not
+ * defined so the gnu89 semantics are the default.
+ */
+#ifdef __GNUC_STDC_INLINE__
+#define __gnu_inline __attribute__((gnu_inline))
+#else
+#define __gnu_inline
+#endif
+
/*
* Force always-inline if the user requests it so via the .config,
* or if gcc is too old.
@@ -72,19 +84,22 @@
* -Wunused-function. This turns out to avoid the need for complex #ifdef
* directives. Suppress the warning in clang as well by using "unused"
* function attribute, which is redundant but not harmful for gcc.
+ * Prefer gnu_inline, so that extern inline functions do not emit an
+ * externally visible function. This makes extern inline behave as per gnu89
+ * semantics rather than c99. This prevents multiple symbol definition errors
+ * of extern inline functions at link time.
+ * A lot of inline functions can cause havoc with function tracing.
*/
#if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
!defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
-#define inline inline __attribute__((always_inline,unused)) notrace
-#define __inline__ __inline__ __attribute__((always_inline,unused)) notrace
-#define __inline __inline __attribute__((always_inline,unused)) notrace
+#define inline \
+ inline __attribute__((always_inline, unused)) notrace __gnu_inline
#else
-/* A lot of inline functions can cause havoc with function tracing */
-#define inline inline __attribute__((unused)) notrace
-#define __inline__ __inline__ __attribute__((unused)) notrace
-#define __inline __inline __attribute__((unused)) notrace
+#define inline inline __attribute__((unused)) notrace __gnu_inline
#endif
+#define __inline__ inline
+#define __inline inline
#define __always_inline inline __attribute__((always_inline))
#define noinline __attribute__((noinline))
--
2.18.0.rc1.244.gcf134e6275-goog
next prev parent reply other threads:[~2018-06-13 21:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-13 21:05 [PATCH v5 0/3] extern inline native_save_fl for paravirt Nick Desaulniers
2018-06-13 21:05 ` Nick Desaulniers [this message]
2018-06-13 21:05 ` [PATCH v5 2/3] x86/asm: add _ASM_ARG* constants for argument registers to <asm/asm.h> Nick Desaulniers
2018-06-14 20:47 ` H. Peter Anvin
2018-06-14 20:59 ` Nick Desaulniers
2018-06-15 0:17 ` H. Peter Anvin
2018-06-20 16:40 ` Nick Desaulniers
2018-06-21 12:28 ` Ingo Molnar
2018-06-15 4:04 ` Sedat Dilek
2018-06-13 21:05 ` [PATCH v5 3/3] x86: paravirt: make native_save_fl extern inline Nick Desaulniers
2018-06-14 13:20 ` [PATCH v5 0/3] extern inline native_save_fl for paravirt Sedat Dilek
2018-06-19 15:03 ` Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180613210518.113983-2-ndesaulniers@google.com \
--to=ndesaulniers@google.com \
--cc=acme@redhat.com \
--cc=akataria@vmware.com \
--cc=akpm@linux-foundation.org \
--cc=andrea.parri@amarulasolutions.com \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=astrachan@google.com \
--cc=boris.ostrovsky@oracle.com \
--cc=brijesh.singh@amd.com \
--cc=caoj.fnst@cn.fujitsu.com \
--cc=geert@linux-m68k.org \
--cc=ghackmann@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jan.kiszka@siemens.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jgross@suse.com \
--cc=joe@perches.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kstewart@linuxfoundation.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manojgupta@google.com \
--cc=mawilcox@microsoft.com \
--cc=michal.lkml@markovi.net \
--cc=mingo@redhat.com \
--cc=mjg59@google.com \
--cc=mka@chromium.org \
--cc=pombredanne@nexb.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=sedat.dilek@gmail.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tstellar@redhat.com \
--cc=tweek@google.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).