From: Philip Herron <philip.herron@embecosm.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org,
Philip Herron <herron.philip@googlemail.com>,
SimplyTheOther <simplytheother@gmail.com>
Subject: Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64
Date: Thu, 28 Jul 2022 11:51:37 +0100 [thread overview]
Message-ID: <CAB2u+n0QNmTo2GbhpVfyLb1m=NBh+1BZdTv6iDeQD=XXxhLihQ@mail.gmail.com> (raw)
In-Reply-To: <878roda5f5.fsf@euler.schwinge.homeip.net>
Hi Thomas,
I think you are right here. There are parts in
libstd/liballoc/libpanic which start to look for what CPU features are
available iirc. Maintaining our patches here has been becoming
difficult as of late, especially when it comes to libcore, which just
cares about target pointer width and endienness which is more
generally available as macros.
It seems more clear now that maybe for this v1 set of patches,
possibly this stuff doesn't really matter right now until we compile
libstd which seems like a much better approach in order to review the
front-end code. I think i will apply your patch and revert these
changes for now since we have the git history for them we can look at
this more closely when we need it.
Thanks
--Phil
On Thu, 28 Jul 2022 at 11:38, Thomas Schwinge <thomas@codesourcery.com> wrote:
>
> Hi!
>
> On 2022-07-27T14:40:38+0100, "herron.philip--- via Gcc-patches" <gcc-patches@gcc.gnu.org> wrote:
> > This patch introduces a new set of interfaces to define the target info as
> > expected by the rust front-end. It takes advantage of the information
> > within gcc/config/target directories which gets called by the front-end
> > to populate rust front-end datastructures by calling into:
> > builtin_rust_info. This patch has been isolated to find if we are
> > approaching this in an idiomatic way and is compilable without the
> > rust-front-end code.
>
> I suppose the general approach may be fine, as is similarly implemented
> by other languages' front ends in GCC.
>
> > We have received many patches here which gives us the target hook info for
> > most platforms
>
> But this is all so much WIP and full of TODO notes, and has no test cases
> at all!, that I still don't really see much value in keeping the current
> implementations of 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc.
> Applying "[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'"
> that I've attached, we're not seeing any change in 'make check-rust'
> results, for example.
>
> In my opinion, the current implementation should be backed out from the
> main development branch (would also reduce pain in merges from GCC
> upstream, as mentioned before), and then be developed (quite possibly
> based on the current implementation) individually for all GCC
> configurations that we'd like to support (with 'sorry' otherwise), in a
> coherent way, instead of trying to guess all possible target options as
> done by the current implementation. And, with all relevant test cases
> getting added, of course. That is, at this time, restrict outselves to
> GCC configurations that we're actually supporting and testing.
>
> Have we even figured out which of those target options are actually
> mandated for a conforming Rust programming language implementation (that
> is, users would potentially rely on these)?
>
> As far as I can tell, 'rustc' defines target options here:
> <https://github.com/rust-lang/rust/tree/master/compiler/rustc_target/src/spec>,
> and you may use 'rustc --print=cfg' to dump for the current
> configuration?
>
> > but getting the normal x86 done correctly will define if
> > the other patches are done correctly.
>
> Yes -- but I'm not sure this is it really, in its current WIPy,
> un-tested, un-verified form:
>
> > gcc/config/ChangeLog:
>
> > * gnu.h: add new macro GNU_USER_TARGET_RUST_OS_INFO
> > * dragonfly.h: define TARGET_RUST_OS_INFO
> > * freebsd-spec.h: define FBSD_TARGET_RUST_OS_INFO
> > * freebsd.h: define guard for TARGET_RUST_OS_INFO
> > * fuchsia.h: define TARGET_RUST_OS_INFO
> > * kfreebsd-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
> > * kopensolaris-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
> > * linux-android.h: define ANDROID_TARGET_RUST_OS_INFO
> > * linux.h: define GNU_USER_TARGET_RUST_OS_INFO
> > * netbsd.h: define NETBSD_TARGET_RUST_OS_INFO
> > * openbsd.h: define OPENBSD_TARGET_RUST_OS_INFO
> > * phoenix.h: define TARGET_RUST_OS_INFO
> > * sol2.h: define TARGET_RUST_OS_INFO
> > * vxworks.h: define VXWORKS_TARGET_RUST_OS_INFO
> > * vxworksae.h: define VXWORKS_TARGET_RUST_OS_INFO
> >
> > gcc/config/i386/ChangeLog:
> >
> > * crtdll.h: define EXTRA_TARGET_RUST_OS_INFO
> > * cygming.h: define TARGET_RUST_OS_INFO
> > * cygwin.h: define EXTRA_TARGET_RUST_OS_INFO
> > * darwin.h: define TARGET_RUST_OS_INFO
> > * djgpp.h: likewise
> > * gnu-user-common.h: define TARGET_RUST_OS_INFO
> > * i386-protos.h: prototype for ix86_rust_target_cpu_info
> > * i386-rust.cc: new file to generate the rust target host info
> > * i386.h: define TARGET_RUST_CPU_INFO hook
> > * linux-common.h: define hooks for target info
> > * lynx.h: likewise
> > * mingw32.h: likewise
> > * netbsd-elf.h: likewise
> > * netbsd64.h: likewise
> > * nto.h: likewise
> > * openbsdelf.h: likewise
> > * rdos.h: likewise
> > * rtemself.h: likewise
> > * t-i386: add makefilke rule for i386-rust.cc
> > * vxworks.h: define TARGET_RUST_OS_INFO
>
>
> Grüße
> Thomas
>
>
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
next prev parent reply other threads:[~2022-07-28 10:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-27 13:40 Rust frontend patches v1 herron.philip
2022-07-27 13:40 ` [PATCH Rust front-end v1 1/4] Add skeleton Rust front-end folder herron.philip
2022-07-27 13:40 ` [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64 herron.philip
2022-07-28 9:57 ` Jakub Jelinek
2022-07-28 10:38 ` Thomas Schwinge
2022-07-28 10:51 ` Philip Herron [this message]
2022-07-28 11:08 ` Thomas Schwinge
2022-07-28 11:41 ` Philip Herron
2022-07-27 13:40 ` [PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM herron.philip
2022-07-27 14:13 ` Richard Earnshaw
2022-07-27 16:45 ` Rust frontend patches v1 David Malcolm
2022-07-28 9:39 ` Philip Herron
2022-08-10 18:56 ` Philip Herron
2022-08-10 19:06 ` David Malcolm
2022-08-12 20:45 ` Mike Stump
2022-08-15 14:07 ` Manuel López-Ibáñez
2022-08-15 14:33 ` Martin Liška
2022-08-24 13:48 ` Martin Liška
2022-08-24 13:51 ` Philip Herron
2022-08-24 14:02 ` Martin Liška
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='CAB2u+n0QNmTo2GbhpVfyLb1m=NBh+1BZdTv6iDeQD=XXxhLihQ@mail.gmail.com' \
--to=philip.herron@embecosm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=herron.philip@googlemail.com \
--cc=simplytheother@gmail.com \
--cc=thomas@codesourcery.com \
/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).