Re: [PATCH v4] lib/string.c: implement a basic bcmp
On Fri, Mar 22, 2019 at 8:17 AM Rasmus Villemoes wrote: > > On 21/03/2019 18.02, Nick Desaulniers wrote: > > On Wed, Mar 20, 2019 at 7:11 PM Andrew Morton > > wrote: > >> > > > > Further, I can drop some of the __GNUC__ < 4 code in > > arch/x86/include/asm/string_32.h. > > Already on its way to Linus: > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=88ca66d8540ca26119b1428cddb96b37925bdf01 > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=2e905c7abdcd5ff09b9df33d25eb7148c85bed2a > Upstream: "x86/asm: Remove dead __GNUC__ conditionals" https://git.kernel.org/linus/88ca66d8540ca26119b1428cddb96b37925bdf01 "x86/asm: Remove unused __constant_c_x_memset() macro and inlines" https://git.kernel.org/linus/2e905c7abdcd5ff09b9df33d25eb7148c85bed2a - Sedat -
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On 21/03/2019 18.02, Nick Desaulniers wrote: > On Wed, Mar 20, 2019 at 7:11 PM Andrew Morton > wrote: >> > > Further, I can drop some of the __GNUC__ < 4 code in > arch/x86/include/asm/string_32.h. Already on its way to Linus: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=88ca66d8540ca26119b1428cddb96b37925bdf01 https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=2e905c7abdcd5ff09b9df33d25eb7148c85bed2a
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On Thu, 21 Mar 2019 10:02:37 -0700 Nick Desaulniers wrote: > Shall I send you a cleanup removing the undefs for bcmp, memcmp, > strcat, strcpy, and strcmp? Of those, I only see memcmp being > `#defined` in arch/m68k/include/asm/string.h, arch/x86/boot/string.h, > and arch/x86/include/asm/string_32.h. > > Further, I can drop some of the __GNUC__ < 4 code in > arch/x86/include/asm/string_32.h. (grepping for __GNUC__, looks like > there's a fair amount of code that can be cleaned up). We should > probably check it since Clang lies about being GCC 4.2 compatible, > which will surely break in horrific ways at some point.\ All sounds good. Some time, when convenient, thanks.
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On Thu, Mar 21, 2019 at 10:02 AM Nick Desaulniers wrote: > > On Wed, Mar 20, 2019 at 7:11 PM Andrew Morton > wrote: > > I guess we should backport this into -stable so that older kernels can > > be built with newer Clang. > > Ah, you're right. I always forget. Is it too late to add > > Cc: sta...@vger.kernel.org > > to the patch in your tree? Just noticed now. Thank you for adding it! -- Thanks, ~Nick Desaulniers
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On Wed, Mar 20, 2019 at 7:11 PM Andrew Morton wrote: > > On Wed, 13 Mar 2019 14:13:31 -0700 Nick Desaulniers > wrote: > > > A recent optimization in Clang (r355672) lowers comparisons of the > > return value of memcmp against zero to comparisons of the return value > > of bcmp against zero. This helps some platforms that implement bcmp > > more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but > > an optimized implementation is in the works. > > > > This results in linkage failures for all targets with Clang due to the > > undefined symbol. For now, just implement bcmp as a tailcail to memcmp > > to unbreak the build. This routine can be further optimized in the > > future. > > > > Other ideas discussed: > > * A weak alias was discussed, but breaks for architectures that define > > their own implementations of memcmp since aliases to declarations are > > not permitted (only definitions). Arch-specific memcmp implementations > > typically declare memcmp in C headers, but implement them in assembly. > > * -ffreestanding also is used sporadically throughout the kernel. > > * -fno-builtin-bcmp doesn't work when doing LTO. > > I guess we should backport this into -stable so that older kernels can > be built with newer Clang. Ah, you're right. I always forget. Is it too late to add Cc: sta...@vger.kernel.org to the patch in your tree? > > > ... > > > > --- a/lib/string.c > > +++ b/lib/string.c > > @@ -866,6 +866,26 @@ __visible int memcmp(const void *cs, const void *ct, > > size_t count) > > EXPORT_SYMBOL(memcmp); > > #endif > > > > +#ifndef __HAVE_ARCH_BCMP > > +/** > > + * bcmp - returns 0 if and only if the buffers have identical contents. > > + * @a: pointer to first buffer. > > + * @b: pointer to second buffer. > > + * @len: size of buffers. > > + * > > + * The sign or magnitude of a non-zero return value has no particular > > + * meaning, and architectures may implement their own more efficient > > bcmp(). So > > + * while this particular implementation is a simple (tail) call to memcmp, > > do > > + * not rely on anything but whether the return value is zero or non-zero. > > + */ > > +#undef bcmp > > What is the undef for? Used the same convention as memcpy. Looking at the rest of the translation unit, I see that there's a mix of functions that do or do not undef their symbol. Rasmus pointed out that memcpy is implemented as a macro for x86 (arch/x86/include/asm/string_32.h). But looking closer now, I suspect it's not needed (anyone declaring memcmp as a macro should be setting __HAVE_ARCH_MEMCMP). Shall I send you a cleanup removing the undefs for bcmp, memcmp, strcat, strcpy, and strcmp? Of those, I only see memcmp being `#defined` in arch/m68k/include/asm/string.h, arch/x86/boot/string.h, and arch/x86/include/asm/string_32.h. Further, I can drop some of the __GNUC__ < 4 code in arch/x86/include/asm/string_32.h. (grepping for __GNUC__, looks like there's a fair amount of code that can be cleaned up). We should probably check it since Clang lies about being GCC 4.2 compatible, which will surely break in horrific ways at some point. -- Thanks, ~Nick Desaulniers
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On Wed, 13 Mar 2019 14:13:31 -0700 Nick Desaulniers
wrote:
> A recent optimization in Clang (r355672) lowers comparisons of the
> return value of memcmp against zero to comparisons of the return value
> of bcmp against zero. This helps some platforms that implement bcmp
> more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but
> an optimized implementation is in the works.
>
> This results in linkage failures for all targets with Clang due to the
> undefined symbol. For now, just implement bcmp as a tailcail to memcmp
> to unbreak the build. This routine can be further optimized in the
> future.
>
> Other ideas discussed:
> * A weak alias was discussed, but breaks for architectures that define
> their own implementations of memcmp since aliases to declarations are
> not permitted (only definitions). Arch-specific memcmp implementations
> typically declare memcmp in C headers, but implement them in assembly.
> * -ffreestanding also is used sporadically throughout the kernel.
> * -fno-builtin-bcmp doesn't work when doing LTO.
I guess we should backport this into -stable so that older kernels can
be built with newer Clang.
> ...
>
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -866,6 +866,26 @@ __visible int memcmp(const void *cs, const void *ct,
> size_t count)
> EXPORT_SYMBOL(memcmp);
> #endif
>
> +#ifndef __HAVE_ARCH_BCMP
> +/**
> + * bcmp - returns 0 if and only if the buffers have identical contents.
> + * @a: pointer to first buffer.
> + * @b: pointer to second buffer.
> + * @len: size of buffers.
> + *
> + * The sign or magnitude of a non-zero return value has no particular
> + * meaning, and architectures may implement their own more efficient bcmp().
> So
> + * while this particular implementation is a simple (tail) call to memcmp, do
> + * not rely on anything but whether the return value is zero or non-zero.
> + */
> +#undef bcmp
What is the undef for?
> +int bcmp(const void *a, const void *b, size_t len)
> +{
> + return memcmp(a, b, len);
> +}
> +EXPORT_SYMBOL(bcmp);
> +#endif
> +
> #ifndef __HAVE_ARCH_MEMSCAN
> /**
> * memscan - Find a character in an area of memory.
> --
> 2.21.0.360.g471c308f928-goog
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On 14/03/2019 10.57, David Laight wrote: > From: Nick Desaulniers >> Sent: 13 March 2019 21:14 > ... >> diff --git a/include/linux/string.h b/include/linux/string.h >> index 7927b875f80c..6ab0a6fa512e 100644 >> --- a/include/linux/string.h >> +++ b/include/linux/string.h >> @@ -150,6 +150,9 @@ extern void * memscan(void *,int,__kernel_size_t); >> #ifndef __HAVE_ARCH_MEMCMP >> extern int memcmp(const void *,const void *,__kernel_size_t); >> #endif >> +#ifndef __HAVE_ARCH_BCMP >> +extern int bcmp(const void *,const void *,__kernel_size_t); >> +#endif > > Shouldn't that prototype always be present? Yes and no. The problem is that asm/string.h may decide to implement bcmp (or memcpy, memset, strcpy, ...) as a macro, which would break rather badly when used to declare the function. And we can't undef the macro temporarily. So I think the convention is that asm/string.h provides the prototype before it #defines the macro, see e.g. arch/x86/include/asm/string_32.h which has a #define of memcpy. There is a fix for the "may be defined as a function-like macro", which is extern int (bcmp)(const void *,const void *,__kernel_size_t); I'd like to see that used rather than the ad hoc convention, but it is of course somewhat unconventional C. Rasmus
RE: [PATCH v4] lib/string.c: implement a basic bcmp
From: Nick Desaulniers > Sent: 13 March 2019 21:14 ... > diff --git a/include/linux/string.h b/include/linux/string.h > index 7927b875f80c..6ab0a6fa512e 100644 > --- a/include/linux/string.h > +++ b/include/linux/string.h > @@ -150,6 +150,9 @@ extern void * memscan(void *,int,__kernel_size_t); > #ifndef __HAVE_ARCH_MEMCMP > extern int memcmp(const void *,const void *,__kernel_size_t); > #endif > +#ifndef __HAVE_ARCH_BCMP > +extern int bcmp(const void *,const void *,__kernel_size_t); > +#endif Shouldn't that prototype always be present? Any architecture specific implementation better have the same definition. This is particularly true here since the compiler is going to assume the default calling convention. The only time you wouldn't want it is when the architecture specific implementation is inline asm. If that were an option the default implementation would need to be excluded using a different #define. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On Wed, Mar 13, 2019 at 02:13:31PM -0700, Nick Desaulniers wrote:
> A recent optimization in Clang (r355672) lowers comparisons of the
> return value of memcmp against zero to comparisons of the return value
> of bcmp against zero. This helps some platforms that implement bcmp
> more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but
> an optimized implementation is in the works.
>
> This results in linkage failures for all targets with Clang due to the
> undefined symbol. For now, just implement bcmp as a tailcail to memcmp
> to unbreak the build. This routine can be further optimized in the
> future.
>
> Other ideas discussed:
> * A weak alias was discussed, but breaks for architectures that define
> their own implementations of memcmp since aliases to declarations are
> not permitted (only definitions). Arch-specific memcmp implementations
> typically declare memcmp in C headers, but implement them in assembly.
> * -ffreestanding also is used sporadically throughout the kernel.
> * -fno-builtin-bcmp doesn't work when doing LTO.
Thanks!
Reviewed-by: Andy Shevchenko
>
> Link: https://bugs.llvm.org/show_bug.cgi?id=41035
> Link: https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp
> Link:
> https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd18eedcff13
> Link: https://github.com/ClangBuiltLinux/linux/issues/416
> Cc: sta...@vger.kernel.org
> Reported-by: Nathan Chancellor
> Reported-by: Adhemerval Zanella
> Suggested-by: Arnd Bergmann
> Suggested-by: James Y Knight
> Suggested-by: Masahiro Yamada
> Suggested-by: Nathan Chancellor
> Suggested-by: Rasmus Villemoes
> Signed-off-by: Nick Desaulniers
> Acked-by: Steven Rostedt (VMware)
> ---
> Changes V3 -> V4:
> * Include the entirety of Rasmus' sugguestion, as per Steven.
> * Change formal parameter identifiers to match the comment.
> Changes V2 -> V3:
> * Adjust comment as per Steven to Rasmus' sugguestion.
> * Pick up Steven's Ack.
> Changes V1 -> V2:
> * Add declaration to include/linux/string.h.
> * Reword comment above bcmp.
>
> include/linux/string.h | 3 +++
> lib/string.c | 20
> 2 files changed, 23 insertions(+)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 7927b875f80c..6ab0a6fa512e 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -150,6 +150,9 @@ extern void * memscan(void *,int,__kernel_size_t);
> #ifndef __HAVE_ARCH_MEMCMP
> extern int memcmp(const void *,const void *,__kernel_size_t);
> #endif
> +#ifndef __HAVE_ARCH_BCMP
> +extern int bcmp(const void *,const void *,__kernel_size_t);
> +#endif
> #ifndef __HAVE_ARCH_MEMCHR
> extern void * memchr(const void *,int,__kernel_size_t);
> #endif
> diff --git a/lib/string.c b/lib/string.c
> index 38e4ca08e757..3ab861c1a857 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -866,6 +866,26 @@ __visible int memcmp(const void *cs, const void *ct,
> size_t count)
> EXPORT_SYMBOL(memcmp);
> #endif
>
> +#ifndef __HAVE_ARCH_BCMP
> +/**
> + * bcmp - returns 0 if and only if the buffers have identical contents.
> + * @a: pointer to first buffer.
> + * @b: pointer to second buffer.
> + * @len: size of buffers.
> + *
> + * The sign or magnitude of a non-zero return value has no particular
> + * meaning, and architectures may implement their own more efficient bcmp().
> So
> + * while this particular implementation is a simple (tail) call to memcmp, do
> + * not rely on anything but whether the return value is zero or non-zero.
> + */
> +#undef bcmp
> +int bcmp(const void *a, const void *b, size_t len)
> +{
> + return memcmp(a, b, len);
> +}
> +EXPORT_SYMBOL(bcmp);
> +#endif
> +
> #ifndef __HAVE_ARCH_MEMSCAN
> /**
> * memscan - Find a character in an area of memory.
> --
> 2.21.0.360.g471c308f928-goog
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On Thu, Mar 14, 2019 at 6:13 AM Nick Desaulniers
wrote:
>
> A recent optimization in Clang (r355672) lowers comparisons of the
> return value of memcmp against zero to comparisons of the return value
> of bcmp against zero. This helps some platforms that implement bcmp
> more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but
> an optimized implementation is in the works.
>
> This results in linkage failures for all targets with Clang due to the
> undefined symbol. For now, just implement bcmp as a tailcail to memcmp
> to unbreak the build. This routine can be further optimized in the
> future.
>
> Other ideas discussed:
> * A weak alias was discussed, but breaks for architectures that define
> their own implementations of memcmp since aliases to declarations are
> not permitted (only definitions). Arch-specific memcmp implementations
> typically declare memcmp in C headers, but implement them in assembly.
> * -ffreestanding also is used sporadically throughout the kernel.
> * -fno-builtin-bcmp doesn't work when doing LTO.
>
> Link: https://bugs.llvm.org/show_bug.cgi?id=41035
> Link: https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp
> Link:
> https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd18eedcff13
> Link: https://github.com/ClangBuiltLinux/linux/issues/416
> Cc: sta...@vger.kernel.org
> Reported-by: Nathan Chancellor
> Reported-by: Adhemerval Zanella
> Suggested-by: Arnd Bergmann
> Suggested-by: James Y Knight
> Suggested-by: Masahiro Yamada
> Suggested-by: Nathan Chancellor
> Suggested-by: Rasmus Villemoes
> Signed-off-by: Nick Desaulniers
> Acked-by: Steven Rostedt (VMware)
Reviewed-by: Masahiro Yamada
> ---
> Changes V3 -> V4:
> * Include the entirety of Rasmus' sugguestion, as per Steven.
> * Change formal parameter identifiers to match the comment.
> Changes V2 -> V3:
> * Adjust comment as per Steven to Rasmus' sugguestion.
> * Pick up Steven's Ack.
> Changes V1 -> V2:
> * Add declaration to include/linux/string.h.
> * Reword comment above bcmp.
>
> include/linux/string.h | 3 +++
> lib/string.c | 20
> 2 files changed, 23 insertions(+)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 7927b875f80c..6ab0a6fa512e 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -150,6 +150,9 @@ extern void * memscan(void *,int,__kernel_size_t);
> #ifndef __HAVE_ARCH_MEMCMP
> extern int memcmp(const void *,const void *,__kernel_size_t);
> #endif
> +#ifndef __HAVE_ARCH_BCMP
> +extern int bcmp(const void *,const void *,__kernel_size_t);
> +#endif
> #ifndef __HAVE_ARCH_MEMCHR
> extern void * memchr(const void *,int,__kernel_size_t);
> #endif
> diff --git a/lib/string.c b/lib/string.c
> index 38e4ca08e757..3ab861c1a857 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -866,6 +866,26 @@ __visible int memcmp(const void *cs, const void *ct,
> size_t count)
> EXPORT_SYMBOL(memcmp);
> #endif
>
> +#ifndef __HAVE_ARCH_BCMP
> +/**
> + * bcmp - returns 0 if and only if the buffers have identical contents.
> + * @a: pointer to first buffer.
> + * @b: pointer to second buffer.
> + * @len: size of buffers.
> + *
> + * The sign or magnitude of a non-zero return value has no particular
> + * meaning, and architectures may implement their own more efficient bcmp().
> So
> + * while this particular implementation is a simple (tail) call to memcmp, do
> + * not rely on anything but whether the return value is zero or non-zero.
> + */
> +#undef bcmp
> +int bcmp(const void *a, const void *b, size_t len)
> +{
> + return memcmp(a, b, len);
> +}
> +EXPORT_SYMBOL(bcmp);
> +#endif
> +
> #ifndef __HAVE_ARCH_MEMSCAN
> /**
> * memscan - Find a character in an area of memory.
> --
> 2.21.0.360.g471c308f928-goog
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On Wed, Mar 13, 2019 at 02:13:31PM -0700, Nick Desaulniers wrote:
> A recent optimization in Clang (r355672) lowers comparisons of the
> return value of memcmp against zero to comparisons of the return value
> of bcmp against zero. This helps some platforms that implement bcmp
> more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but
> an optimized implementation is in the works.
>
> This results in linkage failures for all targets with Clang due to the
> undefined symbol. For now, just implement bcmp as a tailcail to memcmp
> to unbreak the build. This routine can be further optimized in the
> future.
>
> Other ideas discussed:
> * A weak alias was discussed, but breaks for architectures that define
> their own implementations of memcmp since aliases to declarations are
> not permitted (only definitions). Arch-specific memcmp implementations
> typically declare memcmp in C headers, but implement them in assembly.
> * -ffreestanding also is used sporadically throughout the kernel.
> * -fno-builtin-bcmp doesn't work when doing LTO.
>
> Link: https://bugs.llvm.org/show_bug.cgi?id=41035
> Link: https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp
> Link:
> https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd18eedcff13
> Link: https://github.com/ClangBuiltLinux/linux/issues/416
> Cc: sta...@vger.kernel.org
> Reported-by: Nathan Chancellor
> Reported-by: Adhemerval Zanella
> Suggested-by: Arnd Bergmann
> Suggested-by: James Y Knight
> Suggested-by: Masahiro Yamada
> Suggested-by: Nathan Chancellor
> Suggested-by: Rasmus Villemoes
> Signed-off-by: Nick Desaulniers
> Acked-by: Steven Rostedt (VMware)
Reviewed-by: Nathan Chancellor
Tested-by: Nathan Chancellor
Thanks for fixing this better than I did (or tried to)!
> ---
> Changes V3 -> V4:
> * Include the entirety of Rasmus' sugguestion, as per Steven.
> * Change formal parameter identifiers to match the comment.
> Changes V2 -> V3:
> * Adjust comment as per Steven to Rasmus' sugguestion.
> * Pick up Steven's Ack.
> Changes V1 -> V2:
> * Add declaration to include/linux/string.h.
> * Reword comment above bcmp.
>
> include/linux/string.h | 3 +++
> lib/string.c | 20
> 2 files changed, 23 insertions(+)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 7927b875f80c..6ab0a6fa512e 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -150,6 +150,9 @@ extern void * memscan(void *,int,__kernel_size_t);
> #ifndef __HAVE_ARCH_MEMCMP
> extern int memcmp(const void *,const void *,__kernel_size_t);
> #endif
> +#ifndef __HAVE_ARCH_BCMP
> +extern int bcmp(const void *,const void *,__kernel_size_t);
> +#endif
> #ifndef __HAVE_ARCH_MEMCHR
> extern void * memchr(const void *,int,__kernel_size_t);
> #endif
> diff --git a/lib/string.c b/lib/string.c
> index 38e4ca08e757..3ab861c1a857 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -866,6 +866,26 @@ __visible int memcmp(const void *cs, const void *ct,
> size_t count)
> EXPORT_SYMBOL(memcmp);
> #endif
>
> +#ifndef __HAVE_ARCH_BCMP
> +/**
> + * bcmp - returns 0 if and only if the buffers have identical contents.
> + * @a: pointer to first buffer.
> + * @b: pointer to second buffer.
> + * @len: size of buffers.
> + *
> + * The sign or magnitude of a non-zero return value has no particular
> + * meaning, and architectures may implement their own more efficient bcmp().
> So
> + * while this particular implementation is a simple (tail) call to memcmp, do
> + * not rely on anything but whether the return value is zero or non-zero.
> + */
> +#undef bcmp
> +int bcmp(const void *a, const void *b, size_t len)
> +{
> + return memcmp(a, b, len);
> +}
> +EXPORT_SYMBOL(bcmp);
> +#endif
> +
> #ifndef __HAVE_ARCH_MEMSCAN
> /**
> * memscan - Find a character in an area of memory.
> --
> 2.21.0.360.g471c308f928-goog
>
[PATCH v4] lib/string.c: implement a basic bcmp
A recent optimization in Clang (r355672) lowers comparisons of the
return value of memcmp against zero to comparisons of the return value
of bcmp against zero. This helps some platforms that implement bcmp
more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but
an optimized implementation is in the works.
This results in linkage failures for all targets with Clang due to the
undefined symbol. For now, just implement bcmp as a tailcail to memcmp
to unbreak the build. This routine can be further optimized in the
future.
Other ideas discussed:
* A weak alias was discussed, but breaks for architectures that define
their own implementations of memcmp since aliases to declarations are
not permitted (only definitions). Arch-specific memcmp implementations
typically declare memcmp in C headers, but implement them in assembly.
* -ffreestanding also is used sporadically throughout the kernel.
* -fno-builtin-bcmp doesn't work when doing LTO.
Link: https://bugs.llvm.org/show_bug.cgi?id=41035
Link: https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp
Link:
https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd18eedcff13
Link: https://github.com/ClangBuiltLinux/linux/issues/416
Cc: sta...@vger.kernel.org
Reported-by: Nathan Chancellor
Reported-by: Adhemerval Zanella
Suggested-by: Arnd Bergmann
Suggested-by: James Y Knight
Suggested-by: Masahiro Yamada
Suggested-by: Nathan Chancellor
Suggested-by: Rasmus Villemoes
Signed-off-by: Nick Desaulniers
Acked-by: Steven Rostedt (VMware)
---
Changes V3 -> V4:
* Include the entirety of Rasmus' sugguestion, as per Steven.
* Change formal parameter identifiers to match the comment.
Changes V2 -> V3:
* Adjust comment as per Steven to Rasmus' sugguestion.
* Pick up Steven's Ack.
Changes V1 -> V2:
* Add declaration to include/linux/string.h.
* Reword comment above bcmp.
include/linux/string.h | 3 +++
lib/string.c | 20
2 files changed, 23 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index 7927b875f80c..6ab0a6fa512e 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -150,6 +150,9 @@ extern void * memscan(void *,int,__kernel_size_t);
#ifndef __HAVE_ARCH_MEMCMP
extern int memcmp(const void *,const void *,__kernel_size_t);
#endif
+#ifndef __HAVE_ARCH_BCMP
+extern int bcmp(const void *,const void *,__kernel_size_t);
+#endif
#ifndef __HAVE_ARCH_MEMCHR
extern void * memchr(const void *,int,__kernel_size_t);
#endif
diff --git a/lib/string.c b/lib/string.c
index 38e4ca08e757..3ab861c1a857 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -866,6 +866,26 @@ __visible int memcmp(const void *cs, const void *ct,
size_t count)
EXPORT_SYMBOL(memcmp);
#endif
+#ifndef __HAVE_ARCH_BCMP
+/**
+ * bcmp - returns 0 if and only if the buffers have identical contents.
+ * @a: pointer to first buffer.
+ * @b: pointer to second buffer.
+ * @len: size of buffers.
+ *
+ * The sign or magnitude of a non-zero return value has no particular
+ * meaning, and architectures may implement their own more efficient bcmp(). So
+ * while this particular implementation is a simple (tail) call to memcmp, do
+ * not rely on anything but whether the return value is zero or non-zero.
+ */
+#undef bcmp
+int bcmp(const void *a, const void *b, size_t len)
+{
+ return memcmp(a, b, len);
+}
+EXPORT_SYMBOL(bcmp);
+#endif
+
#ifndef __HAVE_ARCH_MEMSCAN
/**
* memscan - Find a character in an area of memory.
--
2.21.0.360.g471c308f928-goog
