Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Aug 2023 09:32:52 +0000
From: "alice" <alice@...ya.dev>
To: <musl@...ts.openwall.com>
Subject: Re: add loongarch64 port v7.

On Tue Aug 15, 2023 at 9:24 AM UTC, Hongliang Wang wrote:
>
> > In fenv.S:
> > 
> >> ++#ifdef __clang__
> >> ++#define FCSR $fcsr0
> >> ++#else
> >> ++#define FCSR $r0
> >> ++#endif
> > 
> > It's not clear to me what's going on here. Is there a clang
> > incompatibility in the assembler language you're working around? Or
> > what? If so that seems like a tooling bug that should be fixed.
> > 
> The GNU assembler cannot correctly recognize $fcsr0, but the
> LLVM IAS does not have this issue, so make a distinction.
> This issue has been fixed in GNU assembler 2.41. but for compatible
> with GNU assembler 2.40 and below, $r0 need reserved.
>
> The linux kernel also has a similar distinction:

the kernel patch checks if the assembler supports fcsr, and then uses that, or
falls back to r.
in this case, you only check for ifdef clang- which means even with binutils
2.41, it will not use fcsr (__clang__ is not defined). don't you need to perform
a similar test, so clang or binutils>=2.41 both use the top path? most likely,
you need a ./configure test.

>
> commit 38bb46f94544c5385bc35aa2bfc776dcf53a7b5d
> Author: WANG Xuerui <git@...0n.name>
> Date:   Thu Jun 29 20:58:43 2023 +0800
>
>      LoongArch: Prepare for assemblers with proper FCSR class support
>
>      The GNU assembler (as of 2.40) mis-treats FCSR operands as GPRs, but
>      the LLVM IAS does not. Probe for this and refer to FCSRs as"$fcsrNN"
>      if support is present.
>
>      Signed-off-by: WANG Xuerui <git@...0n.name>
>      Signed-off-by: Huacai Chen <chenhuacai@...ngson.cn>
>

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.