[PATCH 1/8] ld: Rename aarch64pe emulation target to arm64pe

[Tamar Christina]

Hi Mark,

> On Tue, Jan 3, 2023 at 10:21 AM Mark Harmstone <mark@harmstone.com>
> wrote:
> >
> > Hi Tamar,
> >
> > Is there any practical benefit to this? The emulation "aarch64pe" hasn't yet
> been seen in a released version of binutils, so it's not that anybody's relying
> on it. Giving the emulation a different name from LLVM, then adding a
> workaround so that LLVM still works, seems like it's adding unneeded
> complexity. Plus it also implies that someone will also have to patch LLVM to
> add a workaround the other way round.

The reason for insisting on this change is non-technical in nature.  For a project such
as binutils we always want the primary name to reflect what the architecture calls things.

As a matter of compatibility with other projects we can on top of that accept aliases.

I don't think we'll need to patch LLVM as you typically don't specify the emulation when
using ld.  Most projects that want cross toolchain support lookup the documentation where
we can explicitly point out that the alias is there for compatibility with other toolchains.

Kind Regards,
Tamar

> >
> > It's not like there's any consistency in the emulation naming as it is, as `ld -m
> help` will show you. Of the ELF emulations, some have "elf" at the beginning,
> some at the end, some have "elf32" or "elf64", others (presumably) have it
> implicit, some have underscores, some don't...
> 
> My thoughts. arm64 has always been a bad name and should not be
> referenced anywhere. It is bad that Microsoft and LLVM folks have started
> using it.
> We should be consistent with the elf targets here and use aarch64pe and
> then add an alias just for compatibility reasons with LLVM.
> We should push LLVM folks to the same and everyone over to aarch64
> instead of arm64.
> 
> Thanks,
> Andrew Pinski
> 
> >
> > Mark
> >
> > On 3/1/23 14:54, Tamar Christina wrote:
> > > Hi All,
> > >
> > > After some discussions, we would prefer if instead of renaming
> > > actual emul target (which also renamed the internal macros) that we
> > > provide a `targ_emul_alias` or similar instead.  This would allow us
> > > to keep the current naming as is, while still supporting the the emul as
> supported by clang.
> > >
> > > This would be similar to the already existing targ_alias which is
> > > used to alias the target triples.
> > >
> > > I believe (from a quick look) that this should all be do-able by
> > > modifying configure.ac in a similar way as targ_extra_emuls currently
> does.
> > >
> > > Thanks,
> > > Tamar
> > >
> > >> -----Original Message-----
> > >> From: Martin Storsjö <martin@martin.st>
> > >> Sent: Tuesday, January 3, 2023 2:14 PM
> > >> To: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
> > >> Cc: Tamar Christina <Tamar.Christina@arm.com>; NightStrike
> > >> <nightstrike@gmail.com>; Mark Harmstone <mark@harmstone.com>;
> > >> wej22007@outlook.com; zac.walker@linaro.org; binutils
> > >> <binutils@sourceware.org>; nickc@redhat.com
> > >> Subject: Re: [PATCH 1/8] ld: Rename aarch64pe emulation target to
> > >> arm64pe
> > >>
> > >> On Tue, 3 Jan 2023, Richard Earnshaw via Binutils wrote:
> > >>
> > >>> The problem with arm64 is that it also matches existing configure
> > >>> scripts that use arm* for the 32-bit targets.  I don't think this is a good
> idea.
> > >>> GNU tools have consistently used the official name for all targets.
> > >> This isn't for the name used in triples (which often are matched in
> > >> configure scripts etc), but used for the ld emulation mode - where
> > >> the current MinGW targets use the names "i386pe" for i386 and and
> "i386pep"
> > >> for x86_64. I don't believe it's common to match those emulation
> > >> names in configure scripts - these names are mostly a detail
> > >> between how the compiler driver invokes the linker, and the linker
> itself.
> > >>
> > >> // Martin
> >
> >