On Wed, 4 Jan 2023, Tamar Christina wrote: >> -----Original Message----- >> From: Martin Storsjö >> Sent: Wednesday, January 4, 2023 10:25 AM >> To: nickc@redhat.com >> Cc: Mark Harmstone ; Tamar Christina >> ; Andrew Pinski ; Richard >> Earnshaw ; NightStrike >> ; wej22007@outlook.com; zac.walker@linaro.org; >> binutils >> Subject: Re: [PATCH 1/8] ld: Rename aarch64pe emulation target to arm64pe >> >> On Wed, 4 Jan 2023, Nick Clifton wrote: >> >>> This would create duplicated code sure, but not too much, and it would >>> allow the linker to be compatible with Clang whilst still also >>> retaining the aarch64 moniker preferred by ARM. >> >> As this still is framed as "compatible with Clang" - does this mean that you still >> insist that GCC should use a different emulation name when calling the >> linker, than what Clang does, forcing lld to also start recognizing that new, >> different emulation name - different from the one that has been in place for >> 5 years? > > To be clear, GCC will very likely reject any port upstreaming that uses > Arm64 for the same reason. And GCC is a lot more tightly controlled. > At least if you want upstream support. > > Believe it or not I'm actually trying to help you here, the fact that > clang has called it arm64 is why we want to allow the alias. As I > mentioned before, it just can't be the main name. Right - but in the case of GCC, it wouldn't be the name of a new port - it would only be a single word in a file for passing linker arguments. Just like how "-m i386pep" is passed for x86_64 today here: https://github.com/gcc-mirror/gcc/blob/345dffd0d4ebff7e705dfff1a8a72017a167120a/gcc/config/i386/mingw-w64.h#L74 So regardless of the binutils discussion, are you saying that GCC would reject a patch that adds such an occurance that would pass "-m arm64pe", in a patch that otherwise consistently calls the port "aarch64"? // Martin