[lkml]   [2020]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 03/28] lib/string.c: implement stpcpy
On Thu, Sep 03, 2020 at 01:30:28PM -0700, Sami Tolvanen wrote:
> From: Nick Desaulniers <>
> LLVM implemented a recent "libcall optimization" that lowers calls to
> `sprintf(dest, "%s", str)` where the return value is used to
> `stpcpy(dest, str) - dest`. This generally avoids the machinery involved
> in parsing format strings. `stpcpy` is just like `strcpy` except it
> returns the pointer to the new tail of `dest`. This optimization was
> introduced into clang-12.
> Implement this so that we don't observe linkage failures due to missing
> symbol definitions for `stpcpy`.
> Similar to last year's fire drill with:
> commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
> The kernel is somewhere between a "freestanding" environment (no full libc)
> and "hosted" environment (many symbols from libc exist with the same
> type, function signature, and semantics).
> As H. Peter Anvin notes, there's not really a great way to inform the
> compiler that you're targeting a freestanding environment but would like
> to opt-in to some libcall optimizations (see pr/47280 below), rather than
> opt-out.
> Arvind notes, -fno-builtin-* behaves slightly differently between GCC
> and Clang, and Clang is missing many __builtin_* definitions, which I
> consider a bug in Clang and am working on fixing.
> Masahiro summarizes the subtle distinction between compilers justly:
> To prevent transformation from foo() into bar(), there are two ways in
> Clang to do that; -fno-builtin-foo, and -fno-builtin-bar. There is
> only one in GCC; -fno-buitin-foo.
> (Any difference in that behavior in Clang is likely a bug from a missing
> __builtin_* definition.)
> Masahiro also notes:
> We want to disable optimization from foo() to bar(),
> but we may still benefit from the optimization from
> foo() into something else. If GCC implements the same transform, we
> would run into a problem because it is not -fno-builtin-bar, but
> -fno-builtin-foo that disables that optimization.
> In this regard, -fno-builtin-foo would be more future-proof than
> -fno-built-bar, but -fno-builtin-foo is still potentially overkill. We
> may want to prevent calls from foo() being optimized into calls to
> bar(), but we still may want other optimization on calls to foo().
> It seems that compilers today don't quite provide the fine grain control
> over which libcall optimizations pseudo-freestanding environments would
> prefer.
> Finally, Kees notes that this interface is unsafe, so we should not
> encourage its use. As such, I've removed the declaration from any
> header, but it still needs to be exported to avoid linkage errors in
> modules.
> Reported-by: Sami Tolvanen <>
> Suggested-by: Andy Lavr <>
> Suggested-by: Arvind Sankar <>
> Suggested-by: Joe Perches <>
> Suggested-by: Masahiro Yamada <>
> Suggested-by: Rasmus Villemoes <>
> Signed-off-by: Nick Desaulniers <>

As you mentioned, this is in -next already (via -mm). I think I sent a
tag for this before, but maybe akpm missed it, so for good measure:

Reviewed-by: Kees Cook <>

Kees Cook

 \ /
  Last update: 2020-09-03 23:48    [W:0.277 / U:1.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site