From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 851B23858D20 for ; Wed, 2 Nov 2022 10:41:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 851B23858D20 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1667385699; bh=wACA6bjIItFMJ8TLRr0ZtrFRILKfqH3y9vZcln4+z1o=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=gO3sJbpVYyHrnWEoV5Z/sbdvYlGB1TWpLFAPj+ycMjxIRsZpoAjfxGbMa56a5dKXq OJ1cviRDqg5xiIQTCfVxTQWIQHNyxUBKinNW8fIwdbr45fLUoL8WxF6pqqINWeP7lP KUBmxOYZcLRPi0MIbbNjUJ6dmsSV8Wp79cFud4P4= Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 61D7F6687B; Wed, 2 Nov 2022 06:41:38 -0400 (EDT) Message-ID: <7dac12df4cc8c122bae328d681a4b353a1003693.camel@xry111.site> Subject: Re: [PATCH] LoongArch: Fix ABI related macros in elf.h to keep consistent with binutils[1]. From: Xi Ruoyao To: WANG Xuerui , caiyinyu , Carlos O'Donell , adhemerval.zanella@linaro.org Cc: libc-alpha@sourceware.org Date: Wed, 02 Nov 2022 18:41:36 +0800 In-Reply-To: References: <20221031034334.3027740-1-caiyinyu@loongson.cn> <0a618c5f8c1d5a621e157a6167048c102fd8d501.camel@xry111.site> <51360f07-4965-c6f7-8e30-160c8e6880f7@loongson.cn> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.0 MIME-Version: 1.0 X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROM_SUSPICIOUS_NTLD,GIT_PATCH_0,LIKELY_SPAM_FROM,PDS_OTHER_BAD_TLD,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 2022-11-02 at 14:19 +0800, WANG Xuerui wrote: >=20 > On 2022/11/2 14:13, caiyinyu wrote: > >=20 > > =E5=9C=A8 2022/11/1 =E4=B8=8A=E5=8D=8810:14, Xi Ruoyao =E5=86=99=E9=81= =93: > > > On Tue, 2022-11-01 at 10:02 +0800, caiyinyu wrote: > > >=20 > > > > diff --git a/elf/elf.h b/elf/elf.h > > > >=20 > > > > index 3f08823a30..d51eb75a73 100644 > > > > --- a/elf/elf.h > > > > +++ b/elf/elf.h > > > > @@ -4093,8 +4093,11 @@ enum > > > > =C2=A0=C2=A0=C2=A0#define R_NDS32_TLS_DESC=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 119 > > > >=20 > > > > =C2=A0=C2=A0=C2=A0/* LoongArch ELF Flags */ > > > > -#define EF_LARCH_ABI=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 0x07 > > > > -#define EF_LARCH_ABI_LP64D=C2=A0=C2=A0=C2=A0=C2=A0 0x03 > > > > +#define EF_LOONGARCH_ABI_MODIFIER_MASK 0x07 > > > > +#define EF_LOONGARCH_ABI_SOFT_FLOAT=C2=A0=C2=A0=C2=A0=C2=A0 0x01 > > > > +#define EF_LOONGARCH_ABI_SINGLE_FLOAT=C2=A0=C2=A0 0x02 > > > > +#define EF_LOONGARCH_ABI_DOUBLE_FLOAT=C2=A0=C2=A0 0x03 > > > > +#define EF_LOONGARCH_OBJABI_V1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 0x40 > > > Again, is "LARCH" -> "LOONGARCH" change intentional?=C2=A0 The ABI do= c does > > > not specified the name of these macros...=C2=A0 And we already have R= _LARCH_* > > > so the difference of "LARCH" and "LOONGARCH" seems puzzling. > >=20 > > We will use *LARCH* to keep consistent in glibc and binutils like=20 > > other arches >=20 > Unfortunately it's EF_LOONGARCH_xxx in binutils from day one [1]... BTW= =20 > the inconsistency is also present from day one. >=20 > [1]:=20 > https://sourceware.org/git/?p=3Dbinutils-gdb.git;a=3Dblob;f=3Dinclude/elf= /loongarch.h;h=3Da6341b46791d3f820f6e120cdc82ca30020ca7ab;hb=3DHEAD Fortunately EF_LOONGARCH_xxx in binutils are not a part of the public API of libbfd (i. e. include/elf/loongarch.h is not installed). So I think we should use EF_LARCH_* instead of EF_LOONGARCH_* in every public interface. And we can "fix" binutils later. > > > And is it an option to keep old names there with a warning? > > >=20 > > > #define EF_LARCH_ABI_LP64D __glibc_macro_warning ("EF_LARCH_ABI_LP64D= =20 > > > is deprecated") 0x03 > > >=20 > > I tend to remove it now. > >=20 > While there's very few LoongArch users running fully open-source systems= =20 > (most of them instead running the so-called old world distros which are= =20 > all more or less commercial distros), deprecating for one release might= =20 > be better, although just removing wouldn't cause much harm either. The > current user base of "new world" LoongArch distros are mostly devs or=20 > power users so they know what to expect. I don't have a strong opinion. If you insist to remove it now I won't object. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University