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 567EF3858D1E for ; Wed, 4 Jan 2023 11:36:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 567EF3858D1E 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 304BaVWU021943-304BaVWV021943; Wed, 4 Jan 2023 13:36:31 +0200 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id BAC33A1471; Wed, 4 Jan 2023 13:36:30 +0200 (EET) Date: Wed, 4 Jan 2023 13:36:29 +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-961600257-1672832191=:2685" X-FE-Policy-ID: 3:14:2:SYSTEM X-Spam-Status: No, score=-3.2 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-961600257-1672832191=: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 11:00 AM >> 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 >> >> On Wed, 4 Jan 2023, Tamar Christina wrote: >> >>> 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/i38 >> 6/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"? > > If it's driver only and has no source implications then It might be ok. > But look at this patch, it's not driver only. By renaming the emulation > target it also renamed the internal macros. It makes us have to > maintain the name "arm64" in the source code along with what everything > else calls aarch64 and this has more implications. Ok, thanks for clarifying the concern - I see your point now. // Martin --8323329-961600257-1672832191=:2685--