From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 7ADB13858D35 for ; Tue, 3 Jan 2023 18:21:13 +0000 (GMT) Received: by mail-wr1-x42f.google.com with SMTP id h16so30454062wrz.12 for ; Tue, 03 Jan 2023 10:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=AfFZeZy9MPhSGDt92nHKdNyCrc4YK2UNZe6hKwqxVxo=; b=f3DhXrCgqDXQMa8P+T4gV3aLmPiFqN9QRmyRCLmi+KYZ/Fr0xTL9WkYOgcOjDOmpqg 5hjvnU4smQWlUVk+dslXn9rP8v+SAQB10GY/0NCOnRVuTNF+R5iWfRXSoZK9ATkZ4x2M +Y5+2yRd71FPXU2x1zA50HkvZB+mA5MCzUqBuKtL8REJYy4uEubvsUK87gnCewd+bAnk jUjEhT39cDA8siKa9a6+Yd7k5gVXDLzp35bCyNi+8VrxC68ccGZvspe5efE6y9+IjlTB 5XV/X/9Rj1xDdloQmefdez0xFZKvvKJSqVBwDWNYDlBBQ77i/4sEHXPvAh2XRpYGdqMu lwNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AfFZeZy9MPhSGDt92nHKdNyCrc4YK2UNZe6hKwqxVxo=; b=SHcEbhENbd99BoTQgU18vtAM04yTADBUOYL4pv1OxCJ3twnWdupJLpLtnVRA4/G/1J PjFrDmx/vccddCLwidPTB7ubAh3B1qFrO9DU6CBUgSlcjEF2JIgoqqT5W2SPZXy8qnlI 0fk1wUV71GgTNVu5uMbNqF6Ld6oMCoQcL98oCn7R34SUbk/CUajLg8gDofM5oiMVRp6d s4/OoJOpP5r+tZQr31CyEhG5jNiHkuhnf4Gg9i2/c7VJoQ06yrv1vgtipVatIsdJW2+f oMP2uhXARpbRBYy3IKfvVSuU2xfDGxXp+qpGk5IdJmhB+JVPutK8XSrjKykGIqK+Xr86 ZR6A== X-Gm-Message-State: AFqh2kpGqOgMJOSQyS7Lk7yeSDeB3BKNtJFy/h5sPI+4LHrDTw2b0t93 XjTxsX19BXuXYakzgH35hfQ= X-Google-Smtp-Source: AMrXdXsIgxCL9zrzzQEl2a7y8fczKRwJW1rIpRZKlF7AAz+RsajMIAw/a4Md9dLi9nBAybgfiO/vBg== X-Received: by 2002:a5d:404b:0:b0:288:9c64:e39 with SMTP id w11-20020a5d404b000000b002889c640e39mr13825266wrp.66.1672770072184; Tue, 03 Jan 2023 10:21:12 -0800 (PST) Received: from ?IPV6:2a02:8010:64ea:0:8eb8:7eff:fe53:9d5f? ([2a02:8010:64ea:0:8eb8:7eff:fe53:9d5f]) by smtp.googlemail.com with ESMTPSA id d14-20020adfa40e000000b0029d9ed7e707sm3769627wra.44.2023.01.03.10.21.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Jan 2023 10:21:11 -0800 (PST) Sender: Mark Harmstone Message-ID: <005b709d-acf5-f266-1e4f-41d2c3918ba3@harmstone.com> Date: Tue, 3 Jan 2023 18:21:08 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH 1/8] ld: Rename aarch64pe emulation target to arm64pe To: Tamar Christina , =?UTF-8?Q?Martin_Storsj=c3=b6?= , Richard Earnshaw Cc: NightStrike , "wej22007@outlook.com" , "zac.walker@linaro.org" , binutils , "nickc@redhat.com" References: <20221230024055.31841-1-mark@harmstone.com> <01e2b3d2-ad18-27ba-9761-82d2d521c00e@foss.arm.com> Content-Language: en-US From: Mark Harmstone In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,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: 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. 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... 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ö >> 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 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