Hi Arnd,
On Tue, 2024-01-23 at 14:23 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <[email protected]>
>
> As reported by many people, the nommu SH code runs into a compiler error
> with a newly added syscall:
>
> + {standard input}: Error: displacement to undefined symbol .L105 overflows 8-bit field : => 590, 593
> + {standard input}: Error: displacement to undefined symbol .L135 overflows 8-bit field : => 603
> + {standard input}: Error: displacement to undefined symbol .L140 overflows 8-bit field : => 606
> + {standard input}: Error: displacement to undefined symbol .L76 overflows 12-bit field: => 591, 594
> + {standard input}: Error: displacement to undefined symbol .L77 overflows 8-bit field : 607 => 607, 582, 585
> + {standard input}: Error: displacement to undefined symbol .L97 overflows 12-bit field: => 607
> + {standard input}: Error: pcrel too far: 604, 590, 577, 593, 572, 569, 598, 599, 596, 610 => 610, 574, 599, 569, 598, 596, 601, 590, 604, 595, 572, 577, 593
>
> Avoid the code that triggers this entirely by using the same generic
> uaccess code that m68k and riscv have on nommu.
>
> Link: https://lore.kernel.org/all/[email protected]/
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> arch/sh/include/asm/uaccess.h | 5 +++++
> arch/sh/include/asm/uaccess_32.h | 23 -----------------------
> 2 files changed, 5 insertions(+), 23 deletions(-)
>
> diff --git a/arch/sh/include/asm/uaccess.h b/arch/sh/include/asm/uaccess.h
> index a79609eb14be..b42764d55901 100644
> --- a/arch/sh/include/asm/uaccess.h
> +++ b/arch/sh/include/asm/uaccess.h
> @@ -2,6 +2,7 @@
> #ifndef __ASM_SH_UACCESS_H
> #define __ASM_SH_UACCESS_H
>
> +#ifdef CONFIG_MMU
> #include <asm/extable.h>
> #include <asm-generic/access_ok.h>
>
> @@ -130,4 +131,8 @@ struct mem_access {
> int handle_unaligned_access(insn_size_t instruction, struct pt_regs *regs,
> struct mem_access *ma, int, unsigned long address);
>
> +#else
> +#include <asm-generic/uaccess.h>
> +#endif
> +
> #endif /* __ASM_SH_UACCESS_H */
> diff --git a/arch/sh/include/asm/uaccess_32.h b/arch/sh/include/asm/uaccess_32.h
> index 5d7ddc092afd..e053f2fd245c 100644
> --- a/arch/sh/include/asm/uaccess_32.h
> +++ b/arch/sh/include/asm/uaccess_32.h
> @@ -35,7 +35,6 @@ do { \
> } \
> } while (0)
>
> -#ifdef CONFIG_MMU
> #define __get_user_asm(x, addr, err, insn) \
> ({ \
> __asm__ __volatile__( \
> @@ -56,16 +55,6 @@ __asm__ __volatile__( \
> ".previous" \
> :"=&r" (err), "=&r" (x) \
> :"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
> -#else
> -#define __get_user_asm(x, addr, err, insn) \
> -do { \
> - __asm__ __volatile__ ( \
> - "mov." insn " %1, %0\n\t" \
> - : "=&r" (x) \
> - : "m" (__m(addr)) \
> - ); \
> -} while (0)
> -#endif /* CONFIG_MMU */
>
> extern void __get_user_unknown(void);
>
> @@ -140,7 +129,6 @@ do { \
> } \
> } while (0)
>
> -#ifdef CONFIG_MMU
> #define __put_user_asm(x, addr, err, insn) \
> do { \
> __asm__ __volatile__ ( \
> @@ -164,17 +152,6 @@ do { \
> : "memory" \
> ); \
> } while (0)
> -#else
> -#define __put_user_asm(x, addr, err, insn) \
> -do { \
> - __asm__ __volatile__ ( \
> - "mov." insn " %0, %1\n\t" \
> - : /* no outputs */ \
> - : "r" (x), "m" (__m(addr)) \
> - : "memory" \
> - ); \
> -} while (0)
> -#endif /* CONFIG_MMU */
>
> #if defined(CONFIG_CPU_LITTLE_ENDIAN)
> #define __put_user_u64(val,addr,retval) \
Wouldn't that make these operations slower or do you think that GCC is able
to optimize this well enough?
Also, this is something that should definitely be boot-tested to make sure
this doesn't introduce any regressions.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Tue, Jan 23, 2024, at 14:55, John Paul Adrian Glaubitz wrote:
>
> Wouldn't that make these operations slower or do you think that GCC is able
> to optimize this well enough?
It's only single load/store instructions, so it should make no
difference. If anything, the generic code should allow the compiler
to have better register allocation and produce better output than
the assembler version (which is how this avoids the ICE), but it's
unlikely to be noticeably either.
> Also, this is something that should definitely be boot-tested to make sure
> this doesn't introduce any regressions.
Agree.
Arnd
Hi Arnd,
On Tue, 2024-01-23 at 15:14 +0100, Arnd Bergmann wrote:
> On Tue, Jan 23, 2024, at 14:55, John Paul Adrian Glaubitz wrote:
> >
> > Wouldn't that make these operations slower or do you think that GCC is able
> > to optimize this well enough?
>
> It's only single load/store instructions, so it should make no
> difference. If anything, the generic code should allow the compiler
> to have better register allocation and produce better output than
> the assembler version (which is how this avoids the ICE), but it's
> unlikely to be noticeably either.
I have not seen an ICE on v6.8-rc1 so far. What config was it that triggered it?
> > Also, this is something that should definitely be boot-tested to make sure
> > this doesn't introduce any regressions.
>
> Agree.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Adrian,
On Tue, Jan 23, 2024 at 3:20 PM John Paul Adrian Glaubitz
<[email protected]> wrote:
> On Tue, 2024-01-23 at 15:14 +0100, Arnd Bergmann wrote:
> > On Tue, Jan 23, 2024, at 14:55, John Paul Adrian Glaubitz wrote:
> > >
> > > Wouldn't that make these operations slower or do you think that GCC is able
> > > to optimize this well enough?
> >
> > It's only single load/store instructions, so it should make no
> > difference. If anything, the generic code should allow the compiler
> > to have better register allocation and produce better output than
> > the assembler version (which is how this avoids the ICE), but it's
> > unlikely to be noticeably either.
>
> I have not seen an ICE on v6.8-rc1 so far. What config was it that triggered it?
v6.8-rc1/sh4-gcc12/sh-allmodconfig
v6.8-rc1/sh4-gcc11/sh-allyesconfig
v6.8-rc1/sh4-gcc13/sh-allmodconfig
v6.8-rc1/sh4-gcc13/sh-allyesconfig
e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/15111229/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds