[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXGsQ9K57SvZ74pmD+_=338sGXjc_t+hCXMh-9BPanXnhA@mail.gmail.com>
Date: Mon, 30 Nov 2020 11:11:52 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Antony Yu <swpenim@...il.com>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>,
Russell King <linux@...linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>,
Nathan Chancellor <natechancellor@...il.com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RESEND,PATCH] ARM: fix __div64_32() error when compiling with clang
On Mon, 23 Nov 2020 at 08:39, Antony Yu <swpenim@...il.com> wrote:
>
> __do_div64 clobbers the input register r0 in little endian system.
> According to the inline assembly document, if an input operand is
> modified, it should be tied to a output operand. This patch can
> prevent compilers from reusing r0 register after asm statements.
>
> Signed-off-by: Antony Yu <swpenim@...il.com>
> ---
> arch/arm/include/asm/div64.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h
> index 898e9c78a7e7..809efc51e90f 100644
> --- a/arch/arm/include/asm/div64.h
> +++ b/arch/arm/include/asm/div64.h
> @@ -39,9 +39,10 @@ static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
> asm( __asmeq("%0", __xh)
> __asmeq("%1", "r2")
> __asmeq("%2", "r0")
> - __asmeq("%3", "r4")
> + __asmeq("%3", "r0")
> + __asmeq("%4", "r4")
> "bl __do_div64"
> - : "=r" (__rem), "=r" (__res)
> + : "=r" (__rem), "=r" (__res), "=r" (__n)
> : "r" (__n), "r" (__base)
> : "ip", "lr", "cc");
> *n = __res;
> --
> 2.23.0
>
Agree that using r0 as an input operand only is incorrect, and not
only on Clang. The compiler might assume that r0 will retain its value
across the asm() block, which is obviously not the case.
However, your patch will likely break big-endian, since in that case,
__xh == r0, and so it will appear twice.
Perhaps it would be better to change the type of __rem to unsigned
long long as well?
Powered by blists - more mailing lists