From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 88DD63858D1E for ; Tue, 3 Jan 2023 18:34:08 +0000 (GMT) Received: by mail-pj1-x1032.google.com with SMTP id o21so3620264pjw.0 for ; Tue, 03 Jan 2023 10:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3XY7z2TBPHMoLe7mb5Sv8hvOk/5vfJ7wcRhdu2EAWlQ=; b=cQZD1chdzYzjmUY2d6+vIyDpwhuirZgAWJglGQQngOAjkryqpjKdtYQ5bEhU6dQAUi w9U/4yvWVPLuurkOqf+ZfsBIwCDtpfcZxztUp1waH0PkNwW7yGAeMqOkKFcmkiRwxAEI wjXdppFOmUx3HsdQD0Up/hIxROXJWWQT6KCQeBAcwoM+QRQgiSM1j8HiCQj17hsH52RT VQrVuPyI6QP5emNl8yZZt3cAIIe3lOgjYFwptq3FLwNWyVgcIOuNSy9FEBhxmVeiltur ZMBIv2qjkCnSLchNWJR6FNTzP1VUl8VliAfjjC72bcSckxKpIlqWgzkg4/m78uhdlj2K NeVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3XY7z2TBPHMoLe7mb5Sv8hvOk/5vfJ7wcRhdu2EAWlQ=; b=FquzUZx4IoVtN909a2T2OEaq43ns1H8ZeDxguVG9RJ1+M1Ry2oKrBJpwJ7a+kHoPOR El9LGnBbwB94jM2BJeyxx3QHEMcgfQSN5WXANBymGJFuhbcsPhjC/IKnM+YAYFX4W0ln jQZxFSJ5KayAQNpuj3l6IGwFdVk3BnMhwxPfeuh7rtjbG7a1yJUOgm4SI80lOcrfi8rj XhLpo1Hs0qifVkYtaaajFc8hu3jtSosP67VuxEAFQSZ1BsoYRn9Glu59DRU2K9s24fVD vC/aLCwX+jQeZOvAK3pl3gW4aZoQ3DXMir/qicWl2udeWlUmhPCKqSA3jRArnpzP9kHz cc0g== X-Gm-Message-State: AFqh2kovKxBXNF6Myqz4jgaqeEIi6i4IlSWaCI7s8gZ9v1wZe36uBwk5 hT9wdVZ4/HFNXtNTA6cCa4AQqlEqH7XU9PgK0Do= X-Google-Smtp-Source: AMrXdXu95gCTME1jFIgujDAV+rQOSwDoQcX8KcRKlraSU33TZjKxqTbmKafw6G4rE8PBtmYShr4M7cz1Af8iF9BkGso= X-Received: by 2002:a17:902:8218:b0:192:c6aa:b039 with SMTP id x24-20020a170902821800b00192c6aab039mr636771pln.123.1672770847404; Tue, 03 Jan 2023 10:34:07 -0800 (PST) MIME-Version: 1.0 References: <20221230024055.31841-1-mark@harmstone.com> <01e2b3d2-ad18-27ba-9761-82d2d521c00e@foss.arm.com> <005b709d-acf5-f266-1e4f-41d2c3918ba3@harmstone.com> In-Reply-To: <005b709d-acf5-f266-1e4f-41d2c3918ba3@harmstone.com> From: Andrew Pinski Date: Tue, 3 Jan 2023 10:33:55 -0800 Message-ID: Subject: Re: [PATCH 1/8] ld: Rename aarch64pe emulation target to arm64pe To: Mark Harmstone Cc: Tamar Christina , =?UTF-8?Q?Martin_Storsj=C3=B6?= , Richard Earnshaw , NightStrike , "wej22007@outlook.com" , "zac.walker@linaro.org" , binutils , "nickc@redhat.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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: On Tue, Jan 3, 2023 at 10:21 AM Mark Harmstone 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 addin= g a workaround so that LLVM still works, seems like it's adding unneeded co= mplexity. Plus it also implies that someone will also have to patch LLVM to= add a workaround the other way round. > > It's not like there's any consistency in the emulation naming as it is, a= s `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 (presumab= ly) 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 e= mul target > > (which also renamed the internal macros) that we provide a `targ_emul_a= lias` or similar > > instead. This would allow us to keep the current naming as is, while s= till 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 modify= ing configure.ac in a > > similar way as targ_extra_emuls currently does. > > > > Thanks, > > Tamar > > > >> -----Original Message----- > >> From: Martin Storsj=C3=B6 > >> Sent: Tuesday, January 3, 2023 2:14 PM > >> To: Richard Earnshaw > >> Cc: Tamar Christina ; NightStrike > >> ; Mark Harmstone ; > >> wej22007@outlook.com; zac.walker@linaro.org; binutils > >> ; nickc@redhat.com > >> Subject: Re: [PATCH 1/8] ld: Rename aarch64pe emulation target to arm6= 4pe > >> > >> 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 co= nfigure > >> scripts etc), but used for the ld emulation mode - where the current M= inGW > >> 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 > >