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

From: Nick Desaulniers
Date: Tue Aug 18 2020 - 19:22:25 EST


On Tue, Aug 18, 2020 at 3:05 PM Dávid Bolvanský
<david.bolvansky@xxxxxxxxx> wrote:
>
> st 19. 8. 2020 o 0:00 Nick Desaulniers <ndesaulniers@xxxxxxxxxx> napísal(a):
> >
> > On Tue, Aug 18, 2020 at 2:41 PM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote:
> > >
> > > Note that -fno-builtin-foo seems to mean slightly different things in
> > > clang and gcc. From experimentation, clang will neither optimize a call
> > > to foo, nor perform an optimization that introduces a call to foo. gcc
> > > will avoid optimizing calls to foo, but it can still generate new calls
> > > to foo while optimizing something else. Which means that
> > > -fno-builtin-{bcmp,stpcpy} only solves things for clang, not gcc. It's
> > > just that gcc doesn't seem to have implemented those optimizations.
> >
> > Can you please share some godbolt links that demonstrate these observations?
> Here:
> https://godbolt.org/z/qjo5P6

Ok, when I implemented this version that used -fno-builtin-stpcpy, I
initially+locally had it added to CLANG_FLAGS rather than
KBUILD_CFLAGS, but changed it to KBUILD_CFLAGS because I believed that
BOTH compilers would not lower calls to foo given -fno-builtin-foo.
Since we have evidence that's not the case, maybe that's the final
solution and my final proposal (v3). A summary:

1. v1 "implement stpcpy"
https://lore.kernel.org/lkml/20200815002417.1512973-1-ndesaulniers@xxxxxxxxxx/T/#u
"Please don't provide more unsafe string functions to the kernel"
2. v2 "KBUILD_CFLAGS += -fno-builtin-stpcpy"
https://lore.kernel.org/lkml/20200817220212.338670-1-ndesaulniers@xxxxxxxxxx/T/#t
"-fno-builtin-* doesn't work like that on GCC"
3. v3 "CLANG_FLAGS += -fno-builtin-stpcpy" TODO

I'll argue that providing an implementation of stpcpy while hiding the
declaration from include/lib/string.h "for the possibility that GCC
may one day perform the same libcall optimization" as YAGNI, that we
may cross that bridge by resurrecting v1 (with the removal of the hunk
against include/lib/string.h). This also defers adding more unsafe
string functions in the kernel.

Thoughts before I send the patch and write that up?
--
Thanks,
~Nick Desaulniers