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 <tho...@codesourcery.com> wrote: > > Hi Phil! > > On 2022-07-28T11:51:37+0100, Philip Herron <philip.her...@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 <tho...@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
