lkml.org 
[lkml]   [2022]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v9] kallsyms: Add self-test facility
Date
From: Leizhen (ThunderTown)
> Sent: 16 December 2022 12:02
>
..
> > Moving the m68k version inside lib/string.c makes the test pass, too.
> > So it must be related to the function being inline, and gcc making
> > (incorrect) assumptions...
>
> Yes, it's the compiler's fault. I just replied David Laight:
>
> I added 'volatile' to prevent compiler optimizations, and it's OK now.
>
> diff --git a/arch/m68k/include/asm/string.h b/arch/m68k/include/asm/string.h
> index f759d944c449940..3db81e5a783c72a 100644
> --- a/arch/m68k/include/asm/string.h
> +++ b/arch/m68k/include/asm/string.h
> @@ -42,9 +42,9 @@ static inline char *strncpy(char *dest, const char *src, size_t n)
> #define __HAVE_ARCH_STRCMP
> static inline int strcmp(const char *cs, const char *ct)
> {
> - char res;
> + signed char res;
>
> - asm ("\n"
> + asm volatile ("\n"
> "1: move.b (%0)+,%2\n" /* get *cs */
> " cmp.b (%1)+,%2\n" /* compare a byte */
> " jne 2f\n" /* not equal, break out */

Adding 'volatile' there shouldn't make any real difference.

I'd double-check the asm constraints for the two pointers.
They are modified by the asm, but the caller's variables
must not be changed.

I think that means they need to be normal 'input' parameters
and the result must be in different register (early clobber?).
Currently the pointers are "+r" - which I think means they
are input-output and any caller-supplied variable is
likely to get changed.

David



-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
\
 
 \ /
  Last update: 2022-12-16 14:31    [W:0.056 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site