public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Martin Storsjö" <martin@martin.st>
To: Tamar Christina <Tamar.Christina@arm.com>
Cc: Andrew Pinski <pinskia@gmail.com>,
	Mark Harmstone <mark@harmstone.com>,
	 Richard Earnshaw <Richard.Earnshaw@foss.arm.com>,
	 NightStrike <nightstrike@gmail.com>,
	 "wej22007@outlook.com" <wej22007@outlook.com>,
	 "zac.walker@linaro.org" <zac.walker@linaro.org>,
	 binutils <binutils@sourceware.org>,
	"nickc@redhat.com" <nickc@redhat.com>
Subject: RE: [PATCH 1/8] ld: Rename aarch64pe emulation target to arm64pe
Date: Tue, 3 Jan 2023 22:05:50 +0200 (EET)	[thread overview]
Message-ID: <237bf7b4-576-945a-58dc-245432e2d9@martin.st> (raw)
In-Reply-To: <VI1PR08MB5325215B59D72AB9A49F7A60FFF49@VI1PR08MB5325.eurprd08.prod.outlook.com>

On Tue, 3 Jan 2023, Tamar Christina wrote:

> I don't think we'll need to patch LLVM as you typically don't specify 
> the emulation when using ld.

When cross compiling, then the compiler driver (gcc or clang) will specify 
it.

> Most projects that want cross toolchain support lookup the documentation 
> where we can explicitly point out that the alias is there for 
> compatibility with other toolchains.

Currently, in mingw scenarios, you can have gcc call ld.bfd or ld.lld, and 
you can have clang call either ld.bfd or ld.lld.

Currently clang calls the linker with "-m arm64pe" and ld.lld recognizes 
and handles that same option. If clang calls ld.bfd, then ld.bfd also 
needs to recognize "-m arm64pe".

If gcc decides to go with a different option name than "-m arm64pe", then 
ld.lld will also need to add support for that specific option spelling, 
for the gcc+ld.lld combination to work.

Therefore, this just adds an entirely unnecessary split of the option 
names - why not just stick with the current option name which is in active 
use?

// Martin


  reply	other threads:[~2023-01-03 20:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30  2:40 Mark Harmstone
2022-12-30  2:40 ` [PATCH 2/8] Fix size of external_reloc for pe-aarch64 Mark Harmstone
2022-12-30  2:40 ` [PATCH 3/8] Skip ELF-specific tests when targeting pe-aarch64 Mark Harmstone
2022-12-30  2:40 ` [PATCH 4/8] Skip big-obj test for pe-aarch64 Mark Harmstone
2022-12-30  2:40 ` [PATCH 5/8] Add pe-aarch64 relocations Mark Harmstone
2022-12-30  2:40 ` [PATCH 6/8] Add .secrel32 for pe-aarch64 Mark Harmstone
2022-12-30  2:40 ` [PATCH 7/8] Add aarch64-w64-mingw32 target Mark Harmstone
2022-12-30  2:40 ` [PATCH 8/8] gas: Restore tc_pe_dwarf2_emit_offset for pe-aarch64 Mark Harmstone
2023-01-03 11:54 ` [PATCH 1/8] ld: Rename aarch64pe emulation target to arm64pe Nick Clifton
2023-01-03 11:59 ` NightStrike
2023-01-03 12:09   ` Tamar Christina
2023-01-03 14:08     ` Richard Earnshaw
2023-01-03 14:13       ` Martin Storsjö
2023-01-03 14:54         ` Tamar Christina
2023-01-03 15:51           ` Martin Storsjö
2023-01-03 15:57             ` Tamar Christina
2023-01-03 18:21           ` Mark Harmstone
2023-01-03 18:33             ` Andrew Pinski
2023-01-03 19:07               ` Mark Harmstone
2023-01-03 19:41               ` Tamar Christina
2023-01-03 20:05                 ` Martin Storsjö [this message]
2023-01-04  2:38                   ` Mark Harmstone
2023-01-04  9:51                     ` Nick Clifton
2023-01-04 10:25                       ` Martin Storsjö
2023-01-04 10:35                         ` Tamar Christina
2023-01-04 11:00                           ` Martin Storsjö
2023-01-04 11:08                             ` Tamar Christina
2023-01-04 11:36                               ` Martin Storsjö
2023-01-04 15:02                                 ` Nick Clifton
2023-01-05  2:33                                   ` Mark Harmstone
2023-01-05 11:01                                     ` Nick Clifton
2023-01-05 10:45                                   ` Tamar Christina
2023-01-03 14:14       ` Tamar Christina
2023-01-03 12:53   ` Martin Storsjö

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=237bf7b4-576-945a-58dc-245432e2d9@martin.st \
    --to=martin@martin.st \
    --cc=Richard.Earnshaw@foss.arm.com \
    --cc=Tamar.Christina@arm.com \
    --cc=binutils@sourceware.org \
    --cc=mark@harmstone.com \
    --cc=nickc@redhat.com \
    --cc=nightstrike@gmail.com \
    --cc=pinskia@gmail.com \
    --cc=wej22007@outlook.com \
    --cc=zac.walker@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).