On 2022/12/16 18:40, David Laight wrote:
From: Geert Uytterhoeven
Sent: 15 December 2022 13:25
...
Looks like commit 3bc753c06dd02a35 ("kbuild: treat char as always
unsigned") is to blame.
Changing:
--- a/arch/m68k/include/asm/string.h
+++ b/arch/m68k/include/asm/string.h
@@ -42,7 +42,7 @@ 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"
"1: move.b (%0)+,%2\n" /* get *cs */
fixes strcmp, but the test still fails:
Try 'int res;' and an explicit sign extend (I think):
"3: extb %2\n"
Compilation failed. I tried "return (int)(signed char)res;", it's still failed.
The strcmp() is still wrong if either input string
has characters with the top bit set.
The result needs to be based of the carry flag not
the sign of the byte subtract.
It is too long since I've written m68k asm.
I've checked, all byte operations leave the high 24bits
unchanged.
Currently, only ASCCIs. So it won't be the reason.
So it is possible that gcc is making assumptions and
skipping the sign extend under some circumstances.
Wow, because compare_symbol_name() works properly during the previous binary
search, the compiler must have done something bad. So I add '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 */
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
--
Regards,
Zhen Lei
