[PATCH v2] LoongArch: Set e_flags to 0x40 of ELF while using new relocations.

[Xi Ruoyao]

On Sun, 2022-09-25 at 16:28 +0800, WANG Xuerui wrote:
> > +
> > +         if (elf_elfheader (output_bfd)->e_ident[EI_CLASS] == ELFCLASS32)
> >             interpreter = "/lib32/ld.so.1";
> > -         else if (EF_LOONGARCH_IS_LP64 (flags))
> > +         else if (elf_elfheader (output_bfd)->e_ident[EI_CLASS] == ELFCLASS64)
> >             interpreter = "/lib64/ld.so.1";
> >           else
> >             interpreter = "/lib/ld.so.1";
> > +
> Wait what, are we still carrying the old-world defaults for the 
> interpreter path here? I know it's harmless because in fact it gets 
> overridden by gcc and glibc, but I'd suggest fixing it in a separate 
> patch later for consistency.

It seems not easy to make a "correct" default...  /lib64/ld-linux-
loongarch-lp64d.so.1 will be incorrect for a musl-based target.  Maybe
we can assume Glibc is used because we are the *GNU* linker anyway...

/* snip */

> I'd bikeshed a little and suggest "EF_LOONGARCH_OBJABI_foo" because
> it's actually "ELF object file ABI v1" and not "ELF ABI object v1".

In the doc we say "the ABI version of an ELF object", IMO it's a little
misleading (can trick people to believe it could be used to distinguish
old and new world).  From Wikipedia:

   In computer software, an application binary interface (ABI) is an
   interface between two binary program modules.
   
I'm not sure if the (non-dynamic) relocation types belongs to the concept
of ABI: the linker treats relocatable object files as an input (like how
"vim" treats a text file), instead of a program module.  But I can't come
up with a better terminology for now...

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