All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: joe@perches.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	akataria@vmware.com, boris.ostrovsky@oracle.com,
	brijesh.singh@amd.com, Cao jin <caoj.fnst@cn.fujitsu.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	hpa@zytor.com, "J. Kiszka" <jan.kiszka@siemens.com>,
	jarkko.sakkinen@linux.intel.com, jgross@suse.com,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	kirill.shutemov@linux.intel.com, mingo@redhat.com,
	mjg59@google.com, Matthias Kaehlcke <mka@chromium.org>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	rostedt@goodmis.org, Thomas Gleixner <tglx@linutronix.de>,
	thomas.lendacky@amd.com, Thiebaud Weksteen <tweek@google.com>,
	linux-efi@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	x86@kernel.org, virtualization@lists.linux-foundation.org,
	Alistair Strachan <astrachan@google.com>,
	Manoj Gupta <manojgupta@google.com>,
	Greg Hackmann <ghackmann@google.com>,
	sedat.dilek@gmail.com, tstellar@redhat.com,
	Kees Cook <keescook@google.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	geert@linux-m68k.org, Will Deacon <will.deacon@arm.com>,
	mawilcox@microsoft.com, Arnd Bergmann <arnd@arndb.de>,
	David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v2 1/2] compiler-gcc.h: add gnu_inline to all inline declarations
Date: Thu, 7 Jun 2018 10:26:10 -0700	[thread overview]
Message-ID: <CAKwvOdkUk7ZL8tXgBs0Y+0Y5NVebgAYne_qgdSWWDOvQaWFPhw@mail.gmail.com> (raw)
In-Reply-To: <202492204c2d5bd5ca27307cbca5e44673b739ed.camel@perches.com>

On Tue, Jun 5, 2018 at 10:23 AM Joe Perches <joe@perches.com> wrote:
>
> On Tue, 2018-06-05 at 10:05 -0700, Nick Desaulniers wrote:
> > 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.
> []
> > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> []
> > @@ -72,17 +72,24 @@
> >   * -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.
> >   */
> >  #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, gnu_inline)) notrace
> > +#define __inline__ \
> > +     __inline__ __attribute__((always_inline, unused, gnu_inline)) notrace
> > +#define __inline \
> > +     __inline __attribute__((always_inline, unused, gnu_inline)) notrace
>
> Perhaps these are simpler as
>
> #define __inline__      inline
> #define __inline        inline

Working on this now, going to push v3 soon.  I was wondering more
about these definitions of inline.

Probably want:

#define __inline__ __inline__ inline
#define __inline __inline inline

These are the only references I found to:

__inline__: https://gcc.gnu.org/onlinedocs/gcc/Inline.html
__inline: http://www.keil.com/support/man/docs/armcc/armcc_chr1359124967692.htm

The commit that introduced them was:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a1365647022eb05a5993f270a78e9bef3bf554eb
which was an interesting read.

I get the feeling that the use of __inline__ or __inline (vs inline)
in the kernel may be wrong and their use should be eradicated in the
follow up patch set, but it would be cool if others have additional
insight.

This code in Clang seems to treat them all as the same:
https://github.com/llvm-mirror/clang/blob/1a597eeed3579b4320b62ff55150195482545992/lib/Lex/PPDirectives.cpp#L2285

-- 
Thanks,
~Nick Desaulniers

WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com>
To: joe@perches.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	akataria@vmware.com, boris.ostrovsky@oracle.com,
	brijesh.singh@amd.com, Cao jin <caoj.fnst@cn.fujitsu.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	hpa@zytor.com, "J. Kiszka" <jan.kiszka@siemens.com>,
	jarkko.sakkinen@linux.intel.com, jgross@suse.com,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	kirill.shutemov@linux.intel.com, mingo@redhat.com,
	mjg59@google.com, Matthias Kaehlcke <mka@chromium.org>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	rostedt@goodmis.org, Thomas Gleixner <tglx@linutronix.de>,
	thomas.lendacky@amd.com, Thiebaud Weksteen <tweek@google.com>,
	linux-efi@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	x86@kernel.org, virtua
Subject: Re: [PATCH v2 1/2] compiler-gcc.h: add gnu_inline to all inline declarations
Date: Thu, 7 Jun 2018 10:26:10 -0700	[thread overview]
Message-ID: <CAKwvOdkUk7ZL8tXgBs0Y+0Y5NVebgAYne_qgdSWWDOvQaWFPhw@mail.gmail.com> (raw)
In-Reply-To: <202492204c2d5bd5ca27307cbca5e44673b739ed.camel@perches.com>

On Tue, Jun 5, 2018 at 10:23 AM Joe Perches <joe@perches.com> wrote:
>
> On Tue, 2018-06-05 at 10:05 -0700, Nick Desaulniers wrote:
> > 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.
> []
> > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> []
> > @@ -72,17 +72,24 @@
> >   * -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.
> >   */
> >  #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, gnu_inline)) notrace
> > +#define __inline__ \
> > +     __inline__ __attribute__((always_inline, unused, gnu_inline)) notrace
> > +#define __inline \
> > +     __inline __attribute__((always_inline, unused, gnu_inline)) notrace
>
> Perhaps these are simpler as
>
> #define __inline__      inline
> #define __inline        inline

Working on this now, going to push v3 soon.  I was wondering more
about these definitions of inline.

Probably want:

#define __inline__ __inline__ inline
#define __inline __inline inline

These are the only references I found to:

__inline__: https://gcc.gnu.org/onlinedocs/gcc/Inline.html
__inline: http://www.keil.com/support/man/docs/armcc/armcc_chr1359124967692.htm

The commit that introduced them was:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a1365647022eb05a5993f270a78e9bef3bf554eb
which was an interesting read.

I get the feeling that the use of __inline__ or __inline (vs inline)
in the kernel may be wrong and their use should be eradicated in the
follow up patch set, but it would be cool if others have additional
insight.

This code in Clang seems to treat them all as the same:
https://github.com/llvm-mirror/clang/blob/1a597eeed3579b4320b62ff55150195482545992/lib/Lex/PPDirectives.cpp#L2285

-- 
Thanks,
~Nick Desaulniers

  parent reply	other threads:[~2018-06-07 17:26 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-05 17:05 [PATCH v2 0/2] extern inline native_save_fl for paravirt Nick Desaulniers
2018-06-05 17:05 ` [PATCH v2 1/2] compiler-gcc.h: add gnu_inline to all inline declarations Nick Desaulniers
2018-06-05 17:23   ` Joe Perches
2018-06-05 17:55     ` Nick Desaulniers
2018-06-05 17:55       ` Nick Desaulniers
2018-06-05 19:13     ` Joe Perches
2018-06-05 19:50       ` Nick Desaulniers
2018-06-05 19:50         ` Nick Desaulniers
2018-06-05 21:59         ` Joe Perches
2018-06-05 21:59         ` Joe Perches
2018-06-05 21:59           ` Joe Perches
2018-06-06  8:05       ` Sedat Dilek
2018-06-06  8:05         ` Sedat Dilek
2018-06-06 16:39         ` hpa
2018-06-06 16:39           ` hpa
2018-06-06 16:39           ` hpa
2018-06-08 14:34           ` Sedat Dilek
2018-06-08 14:34             ` Sedat Dilek
2018-06-05 19:13     ` Joe Perches
2018-06-07 17:26     ` Nick Desaulniers [this message]
2018-06-07 17:26       ` Nick Desaulniers
2018-06-07 17:29       ` Nick Desaulniers
2018-06-07 17:29         ` Nick Desaulniers
2018-06-07 18:31       ` Joe Perches
2018-06-07 18:31         ` Joe Perches
2018-06-07 18:51         ` Nick Desaulniers
2018-06-07 18:51           ` Nick Desaulniers
2018-06-07 18:31       ` Joe Perches
2018-06-07 17:33     ` Nick Desaulniers
2018-06-07 17:33       ` Nick Desaulniers
2018-06-05 17:23   ` Joe Perches
2018-06-05 17:05 ` [PATCH v2 2/2] x86: paravirt: make native_save_fl extern inline Nick Desaulniers
2018-06-05 17:28   ` H. Peter Anvin
2018-06-05 17:28     ` H. Peter Anvin
2018-06-05 17:28     ` H. Peter Anvin
2018-06-05 17:28     ` H. Peter Anvin
2018-06-05 17:31     ` H. Peter Anvin
2018-06-05 17:31       ` H. Peter Anvin
2018-06-05 17:31       ` H. Peter Anvin
2018-06-05 17:31       ` H. Peter Anvin
2018-06-05 17:46       ` Sedat Dilek
2018-06-05 17:46         ` Sedat Dilek
2018-06-05 17:52       ` Nick Desaulniers
2018-06-05 17:52         ` Nick Desaulniers
2018-06-05 18:06         ` H. Peter Anvin
2018-06-05 18:06           ` H. Peter Anvin
2018-06-05 21:28   ` Arnd Bergmann
2018-06-05 21:28     ` Arnd Bergmann
2018-06-05 21:31     ` Arnd Bergmann
2018-06-05 21:31       ` Arnd Bergmann
2018-06-05 21:51       ` Nick Desaulniers
2018-06-05 21:51         ` Nick Desaulniers
2018-06-05 21:31     ` Arnd Bergmann
2018-06-05 21:28   ` Arnd Bergmann

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=CAKwvOdkUk7ZL8tXgBs0Y+0Y5NVebgAYne_qgdSWWDOvQaWFPhw@mail.gmail.com \
    --to=ndesaulniers@google.com \
    --cc=akataria@vmware.com \
    --cc=akpm@linux-foundation.org \
    --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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.