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 12:41:50 +0100 [thread overview]
Message-ID: <CAB2u+n0ZqvuqEzHwBa0e8+0oziK1Jw5hcjOUb3JbWUKcMttqGQ@mail.gmail.com> (raw)
In-Reply-To: <8735ellcj8.fsf@dem-tschwing-1.ger.mentorg.com>
That would be brilliant if you could do that! I can spend my time
focused on splitting the front-end into patches. In the meantime,
while you work on that, I will use your patch here to disable the
target hook stuff so that the patches are buildable.
--Phil
On Thu, 28 Jul 2022 at 12:09, Thomas Schwinge <thomas@codesourcery.com> wrote:
>
> Hi Phil!
>
> On 2022-07-28T11:51:37+0100, Philip Herron <philip.herron@embecosm.com> wrote:
> > I think you are right here. There are parts in
> > libstd/liballoc/libpanic which start to look for what CPU features are
> > available iirc.
>
> Aha, good. That -- once we get there ;-) -- shall then guide us on the
> target options we implement, in addition to what we find generally
> necessary for a conforming Rust programming language implementation (as
> I'd mentioned).
>
> > libcore [...] just
> > cares about target pointer width and endienness which is more
> > generally available as macros.
>
> Right, and these are already implemented in
> 'gcc/rust/rust-session-manager.cc:Session::init'. (..., but also should
> get some test cases added; I'll have a look at some point.)
>
> > 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.
>
> Unless this issue is time-critical, let me offer that instead of my
> "[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'",
> I'll cook up a proper patch, removing the implementations of
> 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc., but keeping the
> general infrastructure in place (if I find that makes sense)?
>
>
> Grüße
> Thomas
>
>
> > 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
> -----------------
> 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 11:42 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
2022-07-28 11:08 ` Thomas Schwinge
2022-07-28 11:41 ` Philip Herron [this message]
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+n0ZqvuqEzHwBa0e8+0oziK1Jw5hcjOUb3JbWUKcMttqGQ@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).