All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
To: miguel.ojeda.sandonis@gmail.com
Cc: Jamie.Cunliffe@arm.com, catalin.marinas@arm.com,
	linux-arm-kernel@lists.infradead.org, ojeda@kernel.org,
	rust-for-linux@vger.kernel.org, steve.capper@arm.com,
	will@kernel.org
Subject: Re: [PATCH 1/3] arm64: rust: Enable Rust support for AArch64
Date: Tue, 18 Apr 2023 16:06:16 +0100	[thread overview]
Message-ID: <20230418150616.2247298-1-Jamie.Cunliffe@arm.com> (raw)
In-Reply-To: <CANiq72=cJPCLmbyAJhY3FEwMS4tonPtJspMG7Kb_EAEZ2CFwhg@mail.gmail.com>

On Tue, Jan 31, 2023 at 5:19 PM Will Deacon <will@kernel.org> wrote:
> On Thu, Jan 26, 2023 at 06:56:01PM +0100, Miguel Ojeda wrote:
> > On Thu, Jan 26, 2023 at 5:35 PM Will Deacon <will at kernel.org> wrote:
> > >
> > > Why do we need to specify this stuff here? LLVM already knows about AArch64
> > > and can compute the data-layout string in computeDataLayout(). Can we have
> > > the tools figure this out for us instead, please?
> > 
> > I agree -- the reason we have this for the moment is to provide full
> > control of the target spec, in particular for cases where `rustc` may
> > not provide enough flags to customize exiting builtin target specs
> > and/or may emit warnings for unknown target features etc.
> > 
> > If it is already enough for arm64 to use e.g. the
> > `aarch64-unknown-none` target spec plus flags on top, then we should
> > go for that, because that is the end goal: these target spec files are
> > unstable in the Rust compiler (and not intended to become stable).
> 
> Please confirm that this is the case, but I really think we should be
> aiming for that rather than starting off my specifying this stuff manually.

The json that we generate looks to be almost equivalent (that's why patch 3
exists, to answer your question on that patch). The only difference is the
`aarch64-unknown-none` rustc target sets the LLVM target to also be
`aarch64-unknown-none`, whereas the current target.json uses the
`aarch64-linux-gnu` LLVM target as does Makefile.clang for C code. As you have
been talking about the unknown-none target throughout this thread, I just wanted
to double check that's your intention?

Happy to switch over to using the rustc definition though. I just did it this
way to keep it consistent with the other architectures and not add any more
complexity into the build. On a quick test it does seem to be OK, but I'll
prepare a patch and do some proper testing that it's actually fine to use the
rustc definition though.

WARNING: multiple messages have this Message-ID (diff)
From: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
To: miguel.ojeda.sandonis@gmail.com
Cc: Jamie.Cunliffe@arm.com, catalin.marinas@arm.com,
	linux-arm-kernel@lists.infradead.org, ojeda@kernel.org,
	rust-for-linux@vger.kernel.org, steve.capper@arm.com,
	will@kernel.org
Subject: Re: [PATCH 1/3] arm64: rust: Enable Rust support for AArch64
Date: Tue, 18 Apr 2023 16:06:16 +0100	[thread overview]
Message-ID: <20230418150616.2247298-1-Jamie.Cunliffe@arm.com> (raw)
In-Reply-To: <CANiq72=cJPCLmbyAJhY3FEwMS4tonPtJspMG7Kb_EAEZ2CFwhg@mail.gmail.com>

On Tue, Jan 31, 2023 at 5:19 PM Will Deacon <will@kernel.org> wrote:
> On Thu, Jan 26, 2023 at 06:56:01PM +0100, Miguel Ojeda wrote:
> > On Thu, Jan 26, 2023 at 5:35 PM Will Deacon <will at kernel.org> wrote:
> > >
> > > Why do we need to specify this stuff here? LLVM already knows about AArch64
> > > and can compute the data-layout string in computeDataLayout(). Can we have
> > > the tools figure this out for us instead, please?
> > 
> > I agree -- the reason we have this for the moment is to provide full
> > control of the target spec, in particular for cases where `rustc` may
> > not provide enough flags to customize exiting builtin target specs
> > and/or may emit warnings for unknown target features etc.
> > 
> > If it is already enough for arm64 to use e.g. the
> > `aarch64-unknown-none` target spec plus flags on top, then we should
> > go for that, because that is the end goal: these target spec files are
> > unstable in the Rust compiler (and not intended to become stable).
> 
> Please confirm that this is the case, but I really think we should be
> aiming for that rather than starting off my specifying this stuff manually.

The json that we generate looks to be almost equivalent (that's why patch 3
exists, to answer your question on that patch). The only difference is the
`aarch64-unknown-none` rustc target sets the LLVM target to also be
`aarch64-unknown-none`, whereas the current target.json uses the
`aarch64-linux-gnu` LLVM target as does Makefile.clang for C code. As you have
been talking about the unknown-none target throughout this thread, I just wanted
to double check that's your intention?

Happy to switch over to using the rustc definition though. I just did it this
way to keep it consistent with the other architectures and not add any more
complexity into the build. On a quick test it does seem to be OK, but I'll
prepare a patch and do some proper testing that it's actually fine to use the
rustc definition though.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-04-18 15:07 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25 16:37 [PATCH 0/3] Rust enablement for AArch64 Jamie Cunliffe
2023-01-25 16:37 ` Jamie Cunliffe
2023-01-25 16:37 ` [PATCH 1/3] arm64: rust: Enable Rust support " Jamie Cunliffe
2023-01-25 16:37   ` Jamie Cunliffe
2023-01-25 19:50   ` Vincenzo Palazzo
2023-01-25 19:50     ` Vincenzo Palazzo
2023-01-25 19:56   ` Vincenzo Palazzo
2023-01-25 19:56     ` Vincenzo Palazzo
2023-01-26 16:35   ` Will Deacon
2023-01-26 16:35     ` Will Deacon
2023-01-26 17:56     ` Miguel Ojeda
2023-01-26 17:56       ` Miguel Ojeda
2023-01-31 16:19       ` Will Deacon
2023-01-31 16:19         ` Will Deacon
2023-01-31 16:49         ` Björn Roy Baron
2023-01-31 16:49           ` Björn Roy Baron
2023-01-31 18:55         ` Miguel Ojeda
2023-01-31 18:55           ` Miguel Ojeda
2023-04-18 15:06           ` Jamie Cunliffe [this message]
2023-04-18 15:06             ` Jamie Cunliffe
2023-01-27 14:09   ` Gary Guo
2023-01-27 14:09     ` Gary Guo
2023-05-02 13:41   ` Asahi Lina
2023-05-02 13:41     ` Asahi Lina
2023-01-25 16:37 ` [PATCH 2/3] arm64: rust: Enable PAC support for Rust Jamie Cunliffe
2023-01-25 16:37   ` Jamie Cunliffe
2023-01-25 19:54   ` Vincenzo Palazzo
2023-01-25 19:54     ` Vincenzo Palazzo
2023-01-25 16:37 ` [PATCH 3/3] arm64: rust: Disable neon and fp target features Jamie Cunliffe
2023-01-25 16:37   ` Jamie Cunliffe
2023-01-25 17:49   ` Miguel Ojeda
2023-01-25 17:49     ` Miguel Ojeda
2023-01-25 19:55   ` Vincenzo Palazzo
2023-01-25 19:55     ` Vincenzo Palazzo
2023-01-26 16:37   ` Will Deacon
2023-01-26 16:37     ` Will Deacon
2023-01-25 18:01 ` [PATCH 0/3] Rust enablement for AArch64 Miguel Ojeda
2023-01-25 18:01   ` Miguel Ojeda
2023-03-07  9:32 ` Asahi Lina
2023-03-07  9:32   ` Asahi Lina
2023-03-07 12:17   ` Miguel Ojeda
2023-03-07 12:17     ` Miguel Ojeda

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=20230418150616.2247298-1-Jamie.Cunliffe@arm.com \
    --to=jamie.cunliffe@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=steve.capper@arm.com \
    --cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.