From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by sourceware.org (Postfix) with ESMTPS id BC9E43858D1E for ; Wed, 4 Jan 2023 11:00:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BC9E43858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=martin.st Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=martin.st Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 304B0HZP020050-304B0HZQ020050; Wed, 4 Jan 2023 13:00:17 +0200 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id 80285A1471; Wed, 4 Jan 2023 13:00:16 +0200 (EET) Date: Wed, 4 Jan 2023 13:00:16 +0200 (EET) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: Tamar Christina cc: "nickc@redhat.com" , Mark Harmstone , 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 In-Reply-To: Message-ID: References: <20221230024055.31841-1-mark@harmstone.com> <01e2b3d2-ad18-27ba-9761-82d2d521c00e@foss.arm.com> <005b709d-acf5-f266-1e4f-41d2c3918ba3@harmstone.com> <237bf7b4-576-945a-58dc-245432e2d9@martin.st> <367317ba-108e-fde8-98d2-0be5146f28fa@harmstone.com> <9be055ae-bfd1-b52b-3dd7-7148a6ead287@redhat.com> <8b20aeef-dbd1-6ad2-85c1-d8191c31f540@martin.st> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1634957235-1672830017=:2685" X-FE-Policy-ID: 3:14:2:SYSTEM X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1634957235-1672830017=:2685 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT 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 --8323329-1634957235-1672830017=:2685--