Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

[Nick Desaulniers <ndesaulniers@google.com>]

On Mon, Aug 17, 2020 at 3:44 PM H. Peter Anvin <hpa@zytor.com> wrote:
>
> On 2020-08-17 15:02, Nick Desaulniers wrote:
> > -ffreestanding typically inhibits "libcall optimizations" where calls to
> > certain library functions can be replaced by the compiler in certain
> > cases to calls to other library functions that may be more efficient.
> > This can be problematic for embedded targets that don't provide full
> > libc implementations.
> >
> > -ffreestanding inhibits all such optimizations, which is the safe
> > choice, but generally we want the optimizations that are performed. The
> > Linux kernel does implement a fair amount of libc routines. Instead of
> > -ffreestanding (which makes more sense in smaller images like kexec's
> > purgatory image), prefer -fno-builtin-* flags to disable the compiler
> > from emitting calls to functions which may not be defined.
> >
> > If you see a linkage failure due to a missing symbol that's typically
> > defined in a libc, and not explicitly called from the source code, then
> > the compiler may have done such a transform.  You can either implement
> > such a function (ie. in lib/string.c) or disable the transform outright
> > via -fno-builtin-* flag (where * is the name of the library routine, ie.
> > -fno-builtin-bcmp).
> >
>
> This is arguably exactly the wrong way around.
>
> The way this *should* be done is by opt-in, not opt-out, which by almost
> definition ends up being a game of whack-a-mole, like in this case
> stpcpy(). Furthermore, it is unlikely that people will remember what
> options to flip when and if stpcpy() happens to be implemented in the
> kernel.
>
> 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?

>
> Instead, a compile job with -ffreestanding should be able to provide a
> list of standard C functions that the compiler may call, and thus the
> compiler actually can do the right thing depending on which exact
> functions it would consider calling. This list is probably most easily
> supplied in the form of a header file with #pragma directives.
>
>         -hpa
>
>

Here we have a one line patch for keeping the build green.  If there's
some compiler feature you'd like implemented, let's sit down sometime
and work out the details.  I'll even buy you a beer.  But right now,
sir, the Arby's is on fire.  Please take your soapbox outside.

--
Thanks,
~Nick Desaulniers