Re: [PATCH] LoongArch: Fix ABI related macros in elf.h to keep consistent with binutils[1].

[Xi Ruoyao <xry111@xry111.site>]

On Wed, 2022-11-02 at 14:19 +0800, WANG Xuerui wrote:
> 
> On 2022/11/2 14:13, caiyinyu wrote:
> > 
> > 在 2022/11/1 上午10:14, Xi Ruoyao 写道:
> > > On Tue, 2022-11-01 at 10:02 +0800, caiyinyu wrote:
> > > 
> > > > diff --git a/elf/elf.h b/elf/elf.h
> > > > 
> > > > index 3f08823a30..d51eb75a73 100644
> > > > --- a/elf/elf.h
> > > > +++ b/elf/elf.h
> > > > @@ -4093,8 +4093,11 @@ enum
> > > >    #define R_NDS32_TLS_DESC       119
> > > > 
> > > >    /* LoongArch ELF Flags */
> > > > -#define EF_LARCH_ABI           0x07
> > > > -#define EF_LARCH_ABI_LP64D     0x03
> > > > +#define EF_LOONGARCH_ABI_MODIFIER_MASK 0x07
> > > > +#define EF_LOONGARCH_ABI_SOFT_FLOAT     0x01
> > > > +#define EF_LOONGARCH_ABI_SINGLE_FLOAT   0x02
> > > > +#define EF_LOONGARCH_ABI_DOUBLE_FLOAT   0x03
> > > > +#define EF_LOONGARCH_OBJABI_V1          0x40
> > > Again, is "LARCH" -> "LOONGARCH" change intentional?  The ABI doc does
> > > not specified the name of these macros...  And we already have R_LARCH_*
> > > so the difference of "LARCH" and "LOONGARCH" seems puzzling.
> > 
> > We will use *LARCH* to keep consistent in glibc and binutils like 
> > other arches
> 
> Unfortunately it's EF_LOONGARCH_xxx in binutils from day one [1]... BTW 
> the inconsistency is also present from day one.
> 
> [1]: 
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=include/elf/loongarch.h;h=a6341b46791d3f820f6e120cdc82ca30020ca7ab;hb=HEAD

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?
> > > 
> > > #define EF_LARCH_ABI_LP64D __glibc_macro_warning ("EF_LARCH_ABI_LP64D 
> > > is deprecated") 0x03
> > > 
> > I tend to remove it now.
> > 
> While there's very few LoongArch users running fully open-source systems 
> (most of them instead running the so-called old world distros which are 
> all more or less commercial distros), deprecating for one release might 
> be better, although just removing wouldn't cause much harm either. The
> current user base of "new world" LoongArch distros are mostly devs or 
> 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.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University