public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: "Masahiro Yamada" <masahiroy@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Michal Marek" <michal.lkml@markovi.net>,
	"Linux Kbuild mailing list" <linux-kbuild@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Tony Luck" <tony.luck@intel.com>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Joe Perches" <joe@perches.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Daniel Axtens" <dja@axtens.net>,
	"Arvind Sankar" <nivedita@alum.mit.edu>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Alexandru Ardelean" <alexandru.ardelean@analog.com>,
	"Yury Norov" <yury.norov@gmail.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, "Ard Biesheuvel" <ardb@kernel.org>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	"Daniel Kiper" <daniel.kiper@oracle.com>,
	"Bruce Ashfield" <bruce.ashfield@gmail.com>,
	"Marco Elver" <elver@google.com>,
	"Vamshi K Sthambamkadi" <vamshi.k.sthambamkadi@gmail.com>,
	"Andi Kleen" <ak@suse.de>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Dávid Bolvanský" <david.bolvansky@gmail.com>,
	"Eli Friedman" <efriedma@quicinc.com>
Subject: Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches
Date: Tue, 18 Aug 2020 12:02:32 -0700	[thread overview]
Message-ID: <76071c24-ec6f-7f7a-4172-082bd574d581@zytor.com> (raw)
In-Reply-To: <CAKwvOdk6A4AqTtOsD34WNwxRjyTvXP8KCNj2xfNWYdPT+sLHwQ@mail.gmail.com>

On 2020-08-18 10:56, Nick Desaulniers wrote:
>>
>> The problem here is twofold:
>>
>> 1. The user would be expected to know what kind of the optimizations the
>> compiler can do on what function, which is private knowledge to the
>> compiler.
>>
>> 2. The only way to override -fno-builtin is by a header file with macros
>> overriding the function names with __builtin, but that doesn't tell the
>> compiler proper anything about the execution environment.
>>
>> So the Right Thing is for the compiler authors to change the way
>> -ffreestanding works.
> 
> Sir, this is an Arby's
> 
> There are things all across the compilation landscape that make we
> want to pontificate or even throw a tantrum in an Arby's.  Would I?
> Well, no, I'm just trying to flip burgers or shovel the elephant
> sh...or w/e they do at Arby's (I've never actually been; I detest
> roast beef).
> 
> Would it be interesting to have a way of opting in, as you describe,
> such that your compiler knew exactly what kind of embedded environment
> it was targeting?  Maybe, but I'd argue that opting out is just the
> other side of the same coin. Heads, I win; tails, you lose. That the
> opt in or opt out list is shorter for a given project is not
> particularly interesting.  Should we change the semantics of a fairly
> commonly used compiler flag that multiple toolchains are in agreement
> of, then fix all of the breakage in all of the code that relied on
> those semantics?  I'm afraid that ship may have already
> sailed...probably 20 or 30 years ago.
> 
>> -ffreestanding means, by definition, that there
>> are no library calls (other than libgcc or whatever else is supplied
>> with the compiler) that the compiler can call. That is currently an
>> all-or-nothing choice, or at least one choice per C standard implemented.
> 
> Yes?
> 

I'm not saying "change the semantics", nor am I saying that playing
whack-a-mole *for a limited time* is unreasonable. But I would like to go back
to the compiler authors and get them to implement such a #pragma: "this
freestanding implementation *does* support *this specific library function*,
and you are free to call it." The only way we can get what we really need from
the compilers is by speaking up and requesting it, and we have done so very
successfully recently; further back we tended to get a lot of
language-lawyering, but these days both the gcc and the clang teams have been
wonderfully responsive.

	-hpa


  reply	other threads:[~2020-08-18 19:03 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-17 22:02 [PATCH 0/4] -ffreestanding/-fno-builtin-* patches Nick Desaulniers
2020-08-17 22:02 ` [PATCH 1/4] Makefile: add -fno-builtin-stpcpy Nick Desaulniers
2020-08-17 22:31   ` H. Peter Anvin
2020-08-17 23:36     ` Nick Desaulniers
2020-08-18 19:21     ` Kees Cook
2020-08-18  7:10   ` Ard Biesheuvel
2020-08-18  7:25     ` Greg KH
2020-08-18  7:29       ` Ard Biesheuvel
2020-08-18  7:34         ` Greg KH
2020-08-18 19:23   ` Kees Cook
2020-08-17 22:02 ` [PATCH 2/4] Revert "lib/string.c: implement a basic bcmp" Nick Desaulniers
2020-08-18  5:44   ` Nathan Chancellor
2020-08-18 18:00     ` Nick Desaulniers
2020-08-18 19:24       ` Kees Cook
2020-08-17 22:02 ` [PATCH 3/4] x86/boot: use -fno-builtin-bcmp Nick Desaulniers
2020-08-18 19:24   ` Kees Cook
2020-08-17 22:02 ` [PATCH 4/4] x86: don't build CONFIG_X86_32 as -ffreestanding Nick Desaulniers
2020-08-18 19:24   ` Kees Cook
2021-01-07  0:27   ` Fangrui Song
2020-08-17 22:44 ` [PATCH 0/4] -ffreestanding/-fno-builtin-* patches H. Peter Anvin
2020-08-18 17:56   ` Nick Desaulniers
2020-08-18 19:02     ` H. Peter Anvin [this message]
2020-08-18 19:13       ` Linus Torvalds
2020-08-18 19:25         ` Nick Desaulniers
2020-08-18 19:58           ` Nick Desaulniers
2020-08-19 12:19             ` Clement Courbet
2020-08-18 20:24         ` Arvind Sankar
2020-08-18 20:27           ` Nick Desaulniers
2020-08-18 20:58             ` Nick Desaulniers
2020-08-18 21:41               ` Arvind Sankar
2020-08-18 21:51                 ` Dávid Bolvanský
2020-08-18 21:59                 ` Nick Desaulniers
2020-08-18 22:05                   ` Dávid Bolvanský
2020-08-18 23:22                     ` Nick Desaulniers
2020-08-20 14:56                 ` Rasmus Villemoes
2020-08-20 17:56                   ` Arvind Sankar
2020-08-20 18:05                     ` Dávid Bolvanský
2020-08-20 23:33                     ` Linus Torvalds
2020-08-21 17:29                       ` Arvind Sankar
2020-08-21 17:54                         ` Linus Torvalds
2020-08-21 18:02                           ` Linus Torvalds
2020-08-21 19:14                             ` Arvind Sankar
2020-08-21 19:23                               ` Linus Torvalds
2020-08-21 19:57                           ` Arvind Sankar
2020-08-21 20:03                             ` Peter Zijlstra
2020-08-21 21:39                             ` Linus Torvalds
2020-08-22  0:12                               ` Nick Desaulniers
2020-08-22 12:20                                 ` David Laight
2020-08-21  6:45                     ` Rasmus Villemoes
2020-08-24 15:57                 ` Masahiro Yamada
2020-08-24 17:34                   ` Arvind Sankar
2020-08-25  7:10                     ` Nick Desaulniers
2020-08-25  7:31                       ` Nick Desaulniers
2020-08-25 12:28                       ` Masahiro Yamada
2020-08-25 14:02                         ` Nick Desaulniers
2020-08-26 13:28                           ` Masahiro Yamada
2020-08-18 21:53               ` David Laight
2020-08-20 22:41               ` H. Peter Anvin
2020-08-20 23:17                 ` Arvind Sankar
2020-08-18 19:35       ` Nick Desaulniers
2020-08-18 22:25 ` Arvind Sankar
2020-08-18 22:59   ` Nick Desaulniers
2020-08-18 23:51     ` Arvind Sankar
2020-08-19  0:20     ` Arvind Sankar
2020-08-19  8:26   ` David Laight

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=76071c24-ec6f-7f7a-4172-082bd574d581@zytor.com \
    --to=hpa@zytor.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alexandru.ardelean@analog.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=bruce.ashfield@gmail.com \
    --cc=daniel.kiper@oracle.com \
    --cc=david.bolvansky@gmail.com \
    --cc=dja@axtens.net \
    --cc=dvyukov@google.com \
    --cc=efriedma@quicinc.com \
    --cc=elver@google.com \
    --cc=joe@perches.com \
    --cc=joel@joelfernandes.org \
    --cc=keescook@chromium.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=ndesaulniers@google.com \
    --cc=nivedita@alum.mit.edu \
    --cc=paulmck@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vamshi.k.sthambamkadi@gmail.com \
    --cc=x86@kernel.org \
    --cc=yury.norov@gmail.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