From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 0453C385AE53 for ; Thu, 28 Jul 2022 11:42:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0453C385AE53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-ej1-x632.google.com with SMTP id ss3so2656368ejc.11 for ; Thu, 28 Jul 2022 04:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TMDTbQ1IK6OIhxKbBFFthWmRgXAtZKq+1iticaKhRKQ=; b=OMSJfqpehCXxuSCf/E0BrNZ33/WC3GSct/tFnBfNNMVpvELFtnpgXHPp4/KuxVDQEQ olH18w6siio0k3g2qIllTL/TLYzfbsv/e0zwzfQXo9FqoD2TyncBQ15rpXSofmmoNM/U 2gpBNC3qhdQPzEzocUnrzOJCbS5NZj/LQe7UOXP4+LNZE+rMAZBZxWuot6OErFF48JY4 K4Z2vIn89URkZOapWpDf0ankGEMLjCqCr1J5NKXXu3hFaMsJr9PzD8KL0uxfUC1fAg8q aiaBXJftHx3/DnuUhKLLQjKiYt2nkNx6ciEqP2khjTBcxnqYwXaiTY0FDY5oy/4Zrylo dPSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TMDTbQ1IK6OIhxKbBFFthWmRgXAtZKq+1iticaKhRKQ=; b=uB5AvNxP0HWKfXgWO+FfLm25a53pwYQSud0SQdO56Rei4h1lKUWEluB/0LG2aXEn9h X/1zydMSM/9zaqbhdUUgqSlsRpyG2tT3ugtl7C5HI9ag+vlehqTIxrCRCpl1tqo9DylV 1NKyIppb81fgyQuzXXI4+tK7r6usM9gahappUYntV4z2WVyM9145oWzsDyh/JrYSZLSY 7hBtclKlUoAck+rWDryDbgF2JoLT/kqudZl4Vm37e9y36TctB1xehbs3wlqCQenafciX 0Eo0aJsXFGodngQykoCe+0cv5SWMFdX+1I/II8el7F98mxiY/bCo5JQSlvqPBwCqES8H aihg== X-Gm-Message-State: AJIora9jS7YEo6Md0q/ohDY8Ul0/IrV7QvpKv9gJ5rM7SiZFxs2F3dFg qcCf83nkcNGrGyoYDf6JKDOismkmevIEG01mXYKlfA== X-Google-Smtp-Source: AGRyM1v24cjrp7YHmH/IYHFJHrQ14k5nHf//PSAWk6eWmQtv8XHyYf4iL3UN4103vmh7vFHF/IKYmbuIyWMMVgBQlnU= X-Received: by 2002:a17:907:720f:b0:72f:1c62:8dac with SMTP id dr15-20020a170907720f00b0072f1c628dacmr20838691ejc.437.1659008521522; Thu, 28 Jul 2022 04:42:01 -0700 (PDT) MIME-Version: 1.0 References: <20220727134040.843750-1-philip.herron@embecosm.com> <20220727134040.843750-3-philip.herron@embecosm.com> <878roda5f5.fsf@euler.schwinge.homeip.net> <8735ellcj8.fsf@dem-tschwing-1.ger.mentorg.com> In-Reply-To: <8735ellcj8.fsf@dem-tschwing-1.ger.mentorg.com> From: Philip Herron Date: Thu, 28 Jul 2022 12:41:50 +0100 Message-ID: Subject: Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64 To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org, Philip Herron , SimplyTheOther Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2022 11:42:05 -0000 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 wro= te: > > Hi Phil! > > On 2022-07-28T11:51:37+0100, Philip Herron w= rote: > > 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=C3=BC=C3=9Fe > Thomas > > > > On Thu, 28 Jul 2022 at 11:38, Thomas Schwinge = wrote: > >> > >> Hi! > >> > >> On 2022-07-27T14:40:38+0100, "herron.philip--- via Gcc-patches" wrote: > >> > This patch introduces a new set of interfaces to define the target i= nfo as > >> > expected by the rust front-end. It takes advantage of the informatio= n > >> > 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 implemente= d > >> by other languages' front ends in GCC. > >> > >> > We have received many patches here which gives us the target hook in= fo for > >> > most platforms > >> > >> But this is all so much WIP and full of TODO notes, and has no test ca= ses > >> at all!, that I still don't really see much value in keeping the curre= nt > >> 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 th= e > >> 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 a= s > >> done by the current implementation. And, with all relevant test cases > >> getting added, of course. That is, at this time, restrict outselves t= o > >> 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 (th= at > >> is, users would potentially rely on these)? > >> > >> As far as I can tell, 'rustc' defines target options here: > >> , > >> and you may use 'rustc --print=3Dcfg' 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 in= fo > >> > * 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=C3=BC=C3=9Fe > >> Thomas > >> > >> > >> ----------------- > >> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9F= e 201, 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesc= h=C3=A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesells= chaft: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955 > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 2= 01, 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch= =C3=A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellsc= haft: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955